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PREFACE 


MANUAL OBJECTIVES 


The primary goal of this manual is to introduce RSX-11M-PLUS physical 
I/O concepts, define Executive and I/O service routine protocol, 
describe system I/O data structures, and prescribe I/O service routine 
ceding procedures. This information is in sufficient detail to allow 
you to: 


e Prepare software that interfaces with the Executive = and 
supports a conventional I/0 device 


e Incorporate the user-written software into an RSX-1l1M-PLUS 
system 


e Detect typical errors that cause the system to crash 


e Use Executive service routines that an I/O service routine 
typically employs 


A secondary objective is to introduce advanced hardware and software 
features and sophisticated Executive facilities, and to describe both 
the conventional and advanced features of I/O data structures and 
mechanisms. Knowledge of advanced features’ should facilitate the 
understanding of conventional I/O processing and eliminate some of the 
confusion inherent in seeing data structures without knowing their 
usage. 


The manual does not describe how to write software that incorporates 
advanced driver features. The only complete package of such 
information is DIGITAL-supplied software, such as DVINT.MAC and 
DBDRV.MAC (for overlapped seek, dual access, and common interrupt 
handling); IOSUB.MAC and TTDRV.MAC (for full duplex I/0); and 
MMDRV.MAC (for subcontroller device operation). The manual also does 
not describe how to attach hardware to the PDP-1ll, how to perform 
diagnostic functions to uncover hardware faults, nor how to 
incorporate DIGITAL-standard error-reporting functions in user-written 
software. 


INTENDED AUDIENCE 


This manual is written for the senior-level system programmer who is 
familiar with the hardware characteristics of both the PDP-11 and the 
device that the user-written software supports. The programmer should 
also be knowledgeable about DIGITAL peripheral devices and experienced 
in using the software supplied with an RSX-l11M-PLUS) system. The 
manual neither describes general Executive concepts nor defines 
general system structures. The manual does describe I/O concepts, the 
Executive role in processing I/O requests, and some pertinent aspects 
of I/O processing done by DIGITAL-supplied software. Therefore, with 
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a firm understanding of hardware characteristics and real-time system 
software, a senior-level system programmer should be able to 
apprec.ate how usSer-written software interfacing with the Executive 
can affect overall system performance. 


STRUCTURE OF THIS DOCUMENT 


This dccument is structured to be self-contained so that you need not 
refer to any other manual to build and incorporate a user-written 
driver into your system. The manual has three types of information: 
conceptual, procedural, and reference. The following are abstracts of 
the chapters in the document: 


e Chapter 1, "RSX-11M-PLUS I/O Drivers," introduces terms’ and 
concepts fundamental to understanding physical I/0 in 
RSX-11M-PLUS, and describes the protocol that a driver must 
follow to preserve system integrity. It summarizes advanced 
driver features and RSX-11M-PLUS capabilities helpful in 
becoming acquainted with overall Executive and driver 


interaction. 


e Chapter 2, "Device Driver I/O Structures," continues’ the 
conceptual discussion begun in Chapter 1. It introduces on a 
general level the software data structures involved in 


handling I/O operations at the device level; examines typical 
arrangements of data structures that are necessary for 
controlling hardware functions; and presents a macroscopic 
software configuration that summarizes the logical 
relationships of the I/O data structures. 


e Chapter 3, "Executive Services and Driver Processing," ends 
the conceptual presentation. It summarizes how an I/0 request 
originates; how the Executive processes the request; and how 
a driver would use Executive services to satisfy an I/0 
request. 


e Chapter 4, "Programming Specifics for Writing an I/O Driver," 
provides the detailed reference information necessary to code 
a conventional I/O driver. Included is a summary of 
programming standards and protocol; an introduction to the 
Programming facilities and requirements for both the driver 
data base itself and the executable code that constitutes the 
driver; and an extensive elaboration of the driver data base 
and of the driver code. 


e Chapter 5, "Incorporating A User-Supplied Driver into 
RSX-11M-PLUS," supplies the procedural information that you 
need to assemble and build a loadable driver image, load it 
into memory, and make accessible the devices that the driver 
Supports. Also included are a summary of the system 
generation dialogue concerning including usSer-supplied drivers 
and a description of the loading mechanism and the diagnostic 
operations performed during loading. 


e Chapter 6, “Debugging A User-Supplied Driver," summarizes 
software features provided to help you uncover faults in 
drivers and gives procedures to follow that might prove 
successful in isolating faults in drivers. 


e Chapter 7, “Executive Services Available to An I/O Driver," 
gives general coding information relating to the PDP-11 and 
RSX-1L1IM-PLUS Executive service routines. 


PREFACE 


e Chapter 8, "Sample Driver Code," shows the source code for the 
data base and driver of a conventional device and an excerpt 
of source code from a driver that handles special user 
buffers. 


e Appendix A, "System Data Structures and Symbol Definitions," 
lists the source code of system macro calls that define system 
device structures, driver-related structures, and system-wide 
Symbolic offsets needed to access those structures. 


e Appendix B, "Converting a User-Supplied RSX-11M Driver," 
describes the modifications that you must make to enable an 
RSX-11M user-supplied driver to run on an RSX-11M-PLUS system. 


ASSOCIATED DOCUMENTS 


Accompanying your RSX-11M-PLUS system are documents that describe both 
the software and hardware on the system. The software documents are 
listed and described in the RSX-11M-PLUS Information Directory and 
Index. Consult the directory for concise summaries of 
software-related publications. Processor and peripherals handbooks 
Summarize hardware information published in various maintenance, 
installation, and operator manuals that are provided with your system. 


xi 


SUMMARY OF TECHNICAL CHANGES 


This revision of the RSX-11M-PLUS Guide to Writin an I/O Driver 
nd add 


incorporates the following technical changés a 


additions: 


Two new arguments (BUF and OPT) have been added to the DDT$ 
macro call in Chapter 4. 


The I/O Function Masks for Mass Storage, Magtape, and Unit 


Record Devices have been added in Chapter 4. 
Additions have been made to the UCB in Chapter 4 as follows: 


e A new symbolic name U.MUP has been added (redefinition of 
U.CLI) 


e The DV.MXD offset to U.CWl has been renamed to DV.MSD for 
mass storage. 


e U.UCBX has been added for mass errorlogging 


devices. 


storage 


New status control block extension bit definitions (S2.OPT, 
S$2.O0P1, S2.0P2, and S3.O0PT) have been added to the SCB in 
Chapter 4. 


New controller bit definitions (KS.MOF, KS.EXT and KS.SLO) 


have been added to the KRB in Chapter 4. 


The Queue Optimization entry point, Deallocation entry point 
and the Next command entry point have been added to Chapter 
4. 


New tracing faults of S$HEADR have been added to Chapter 6. 


Some Executive routines listed in Chapter 7 have been moved 
to new Executive modules and 12 have been added. The 
following is a list of the affected modules and subroutines, 
plus the additions: 


Routine Old Module New Module 
SACHKB IOSUB EXSUB 
SACHCK IOSUB EXSUB 
SASUMR IOSUB MEMAP 
SBLKCK IOSUB MDSUB 
SBLKC1 (new) MDS UB 
SBLKC2 (new) MDS UB 
SBLXIO (new) BFCTL 
SCKBFI (new) EXESB 
SCKBFR (new) EXESB 
SCKBEW (new) EXESB 
SCKBFB (new) EXESB 
SCVLBN IOSUB MDSUB 
SDEUMR IOSUB MEMAP 


xiii 


SUMMARY OF TECHNICAL CHANGES 


Routine Old Module New Module 
SINIBF (new) IOSUB 
SMPUBM IOSUB MEMAP 
SMPUB1 IOSUB MEMAP 
SRELOC IOSUB MEMAP 
SRELOP IOSUB MEMAP 
SREQUE (new) IOSUB 
SREQU1 (new) IOSUB 
SSTMAP IOSUB MEMAP 
SSTMP1 IOSUB MEMAP 
STSPAR (new) REQSB 
STSTBF (new) IOSUB 


xiv 
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RSX-11M-PLUS I/O DRIVERS 


Device drivers on RSX-11M-PLUS are the primary method of interfacing 
Executive software with hardware attached to the computer. Most 
DIGITAL-supplied hardwarel is supported by drivers accompanying the 
remaining software that the user receives with the system. This 
chapter introduces the concept of device drivers and explains driver 
operations and features. 


1.1 VECTORS AND CONTROL AND STATUS REGISTERS. 


A device controller has a unique address on the PDP-ll UNIBUS' that 
identifies itself and distinguishes it from other hardware attached to 
the computer. At this unique address is usually a control and status 
register (CSR) containing data elements that allow software to operate 
and interrogate the related device. The CSR resides in physical 
address space that is reserved for device registers and is referred to 
as the I/O, or peripheral, page. Other registers associated with the 
device are placed in contiguous addresses lower and/or higher than the 
CSR address. Software usually controls a device by accessing the CSR 
to enable interrupts, initiate a function, and respond to the 
resulting interrupt to continue or finish the function. 


Associated with many devices can be one or more 2-word areas called 
interrupt vectors. A vector provides a connection between the device 
and the software that services the device. A vector allows a device 
to trigger certain software actions because of some external condition 
related to the device. When ~*~ device interrupts, it sends’ the 
processor the address of the interrupt vector. The first word of the 
interrupt vector contains the address of the interrupt service routine 
for that device. The processor uses the second word of the vector as 
a new Processor Status Word. Thus, when the processor’ services’ the 
interrupt, the first word of the vector is taken as the new Program 
Counter (PC) and the second word is the new PS. 


Space is reserved on the PDP-1ll for the interrupt vectors. This space 
is in the low part of Kernel I-space. The vectors are considered to 
be in Kernel mode virtual address space and are thus mapped by the 
Executive. Because the interrupt vector is in Kernel space, the 
Executive receives control of the processor on every interrupt. On a 
multiprocessor system, each central processor unit has its own vector 
space. 


l. The CINTS directive enables a privileged task to gain control when 
a device interrupts and thereby to access device registers. The 
K-series Laboratory modules use this feature to perform I/O. The 
CINTS directive is a secondary but equally viable method of 
interfacing software to hardware. 
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1.2 SERVICE ROUTINES 


The service routine that is entered to process an interrupt is most 
frequertly in the device driver. Device drivers vary in complexity 
depending on the capabilities of the type of device and the number of 
device units they service. A driver can reside with the Executive 
itself or can be separated from it. The former driver is resident and 
the latter is loadable. 


The distinction between resident and loadable drivers is mainly one of 
flexibility. A resident driver is built in during system generation 
aS a permanent part of the Executive.l It resides in the Executive 
address space and cannot be removed. A resident driver responds to 
interrupts slightly faster than a loadable driver. Although linked 
into the Executive structures, a loadable driver resides in memory 
outside the virtual address space of the Executive. A user can add or 
remove a loadable driver by means of an MCR or VMR command. In 
addition, any driver not required for a period of time need not be 
loaded. The space normally occupied by the unloaded driver can hold 
user tasks or another driver. On a system without Executive data 
space support, making a driver loadable frees virtual space in the 
Executive which can be used for additional pool. 


1.2.1 Executive and Driver Layout 


A device driver is a logical extension of the Executive that need not 
be contiguous in physical memory with the Executive code. Active Page 
Registers (APRs) 0 through 4 map the Executive, whereas APR 7 is 
reserved to map the I/O page.2 Resident drivers are mapped within the 
Executive space. Loadable drivers reside in a separate partition of 
memory and are mapped by APR 5. Therefore, a loadable driver is by 
default restricted to the 4K words of space mapped by APR 5 unless it 
controls itsS own mapping with APR 6 to gain access to an extra 4K 
words. 


The virtual to physical mapping on a system with Kernel data space 
support is shown in Figure l1-l. 


Virtual addresses 0 through 4K words (APR 0) of I and D space overmap 
the same physical memory. The mapped area contains the interrupt 
vectors, processor stack, processor-Specific memory locations, and 
interrupt control block (ICB) pool space as well as some Executive 
code. I-space virtual addresses 4K through 20K words (APR1 through 
APR 4) map the remaining Executive code, which is therefore limited to 
16K words. D-space virtual addresses 4K through 20K words (APR 1 
through APR 4) map the dynamic storage region (or pool) and system 
data structures to a maximum of 16K words. 


1. On systems with Executive data space support, all drivers must be 
loadable. 


2. Active Page Register is a term referring to the KT1l1l Memory 
Management register pair (Page Address Register (PAR) and Page 
Descriptor Register (PDR).) Refer to the relevant processor handbook 
for information on hardware mapping and memory management. Refer to 
the RSX-11M/RSX-11M-PLUS Task Builder Manual for a description of 
mapping and APR assignments by software. 
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Figure 1-1 Virtual to Physical Mapping for the Executive 


Virtual addresses 20K through 28K words (APR 5 and APR 6) of I and D 
space overmap the same physical memory, which is reserved to map 
loadable drivers and privileged tasks in Kernel mode. (Although APR5 
and APR6 are reserved for drivers, the Executive maps only APR5 when 
it calls a driver.) Finally, virtual addresses 28K through 32K words 
(APR 7) of I and D space overmap the I/0 page. 


Thus, a device driver is mapped with the Executive code and the I/0 
page. When a driver has control, it can access the device registers 
in the I/O page to perform its operations. It also has available all 
the Executive service routines to help it process I/O requests. 


Because of the layout of the Executive and device drivers, many common 
functions related to I/O are centralized in the Executive as service 
routines. This commonality eliminates the inclusion of repetitive 
coding in each and every driver. Coding in each driver is therefore 
reduced to handling the specific functions of the device supported. 
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1.2.2 Driver Contents 3 


A dev.ce driver consists of two parts. One part is the executable 
instructions of the driver itself. This part has the entry points to 
the driver. The entry points are those places where the Executive 
calls the driver to perform a specific action, and their addresses are 
estab] ished in the driver dispatch table (DDT). The table contains 
addresses of routines in a fixed orde: so that the Executive can enter 
the driver at the appropriate place for a given action. 


The other part of a device driver is the data structures forming the 
data base that describes the controllers and units supported by the 
driver. Two structures, the controller table (CTB) and the controller 
request block (KRB), describe the controller of the device being 
Supported. Because the CTB supplies generic information about’ the 
contrcelier type, only one CTB need exist for each controller type on a 
syster. The KRB holds information related to a specific controller 
and therefore each controller has its associated KRB. 


Three structures in the driver data base--the device control block 
(DCB), the unit control block (UCB), and the status control block 
(SCB)--describe the device as a logical entity. The DCB contains 
information related to the type of device, whereas the UCB holds 
information specific to an individual unit of the device. The SCB is 
used mainly to store data (driver context) concerning an operation in 
Progress on the device unit. 


The code of a driver must be in one continuous portion of main memory. 
Because the Executive is designed to respond to real-time activities, 
the driver code must run as fast as possible. Therefore, it cannot be 


overlaid. 


The driver data structures are tailored to the number of controllers 
on the system, the number of units attached to each controller, and 
the types of features the devices support. The structures increase in 
complexity as the number of supported features increases. 


1.3 EXECUTIVE AND DRIVER INTERACTION 


The Executive and a driver interact by accessing and manipulating 
common data structures. An I/O activity typically begins when a task 
generates a request for input or output. The Executive performs 
preliminary processing of that request before it initiates the driver. 
This preliminary processing, called predriver initiation, iS common 
for all drivers and eliminates a great deal of code from all drivers. 


In perzorming predriver initiation, the Executive accesses the driver 
data structures to assess the legality of the I/O request. For 
example, cells in the device control block (DCB) define the functions 
that che driver supports. If the function specified in the I/0 
reques:. is not supported by the driver, the Executive need not call 
the driver. The driver is not aware of the I/O request. Therefore, 
the Executive calls the driver only when the predriver initiation 
warrants it. 


1.3.1 The Driver Process 


When the Executive does call the driver to process an I/O request, the 
driver begins I/0 initiation. Once an I/O request is created, a 
driver process is initiated. The Executive has queued to the driver 
an I/0 packet that must be processed to satisfy the request. 
Potentially there exist on the system aS many driver processes as 
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there are distinct units capable of being active simultaneously. 
(Moreover, some drivers supporting advanced features can have multiple 
I/O requests simultaneously active for a given unit. In this case, 
each active I/O request is part of a separate driver process. Refer 
to Section 1.4.7 for more information.) 


Central to a full understanding of a driver and the I/O structure is 
the difference between a driver process and the driver code. The 
driver code, which is pure instructions, invokes an Executive routine 
called S$GTPKT to get an I/O packet to process. This activity 
generates data for the request being processed and the unit doing the 
processing. The driver process, once initiated, starts the proper I/0 
function, waits for a completion interrupt, posts I/O status, and 
requests another I/0 packet. This sequence of execution steps 
continues until the I/O queue is empty. The driver process’ then 
terminates. 


Because a driver may be capable of servicing several I/O requests in 
parallel, it is possible that, for a single driver, many driver 
Processes exist at the same time. However, there is only one copy of 
driver code. The driver process is reentrant code and the data that 
defines the state of the code is stored in the driver data base when 
the process is not executing (for example, when it is waiting for an 
interrupt). The driver process executes driver code for a particular 
device type on behalf of a specific unit. If independent units of a 
particular device type are concurrently active, several driver 
Processes are also active at the same time, each with its own set of 
data. 


1.3.2 Interrupt Dispatching and the Interrupt Control Block 


Once a driver starts an I/O function, it must await the I/O completion 
interrupt. When a device interrupt occurs, the processor pushes the 
current PS and PC onto the current stack and loads the new PS and PC 
from the device controller interrupt vector. By convention, the PS in 
the interrupt vector is preset with a priority of 7 and the number of 
the controller associated with the vector. (The controller number is 
in the low-order four bits.) 


Because an interrupt must be serviced in Kernel address space, how the 
interrupt is handled depends on whether the driver is resident or 
loadable. A resident driver, being mapped with the Executive in 
Kernel address space, handles the interrupt directly (that is, the 
entry point address of the driver is the PC word of the interrupt 
vector). For a resident driver, then, the hardware dispatches 
directly to the interrupt service routine in the driver. Figure 1-2 
shows this mechanism. 


RESIDENT 


RIVER 
CONTROLLER eee 
NUMBER 


INTERRUPT 
VECTOR 
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Figure 1-2 Interrupt Dispatching for a Resident Driver 
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When tle interrupt service routine in the resident driver gains 
contro], it runs) at priority 7, which locks out further interrupts. 
The driver is therefore uninterruptable and, because the system must 
Sedat to real-time events, processing at this level cannot take too 
long. 


To ensure that a driver does not lock out other interrupts on the 
system or destroy the context of any interrupted process, a protocol 
has been established. By system convention, no process should run at 
an un:nterruptable level for more than 100 microseconds. A common 
Execut: ve coroutine, called interrupt save (S$INTSV), exists to lower 
the priority level of the driver process to that of the interrupting 
device and to save two registers of the interrupted process. 
Therefore, by system convention, all resident drivers call the SINTSV 
corout: ne, which saves the PS and extracts the controller number. 
Because most instructions change the PS bits that encode the 
contro..ler number, under most circumstances the driver can do very 
little else without saving the controller number. 


The SINTSV coroutine saves two registers, R4 and R5, which are 
thereaiter free for the driver to use. These registers are typically 
used by drivers to hold addresses of the data blocks containing unit 


Status and control information, the SCB and UCB. (Most Executive 
routines assume these two registers hold pointers to the two 
structures, If the driver needs to uSe more registers, it saves them 


on the stack and restores them when it finishes.) When the interrupt 
Save coroutine returns to the driver, the driver runs at the interrupt 
level of the device that it is servicing and has two free registers 
that rt can use. This protocol makes the driver partially 
interruptable (that is, interruptable by devices with a higher 
priority) and preserves the context of the interrupted process. 


The dr.ver may then run for a short interval at the partially 
interrtiptable level. By convention, this interval should not exceed 
500 microseconds. When the driver finishes processing the interrupt, 
it ma’ execute a RETURN instruction to transfer control back to the 
corout ne which gives control of the CPU to the next process.2 


For a .oadable driver, the hardware cannot dispatch directly to the 
interrupt service routine in the driver because the driver is mapped 
outside the address space of the Executive. Therefore, some code in 
the Executive must ainitially handle the interrupt, load the mapping 
context of the driver, and dispatch to the proper driver. This code 
resides in the Executive in a structure called an interrupt control 
block ICB). Figure 1-3 shows this mechanism. 


The ICB actually contains a JSR instruction to an Executive interrupt 
save routine (SINTSI) and some data cells that enable the routine to 
do the following: 


e Save R4 and R5 


e Save the Kernel mapping (APR 5) 


l. On «a multiprocessor system, a driver running at priority 7 is 
interrwuptable by a device of the same type on another CPU. To handle 
this s.tuation, the driver being interrupted does not have to do any 
specia. processing beyond what is described in this manual. 


2. An Executive interrupt exit rout.ne, YiNTXT, exists to standardize 


the way a driver exits from an interrupt. However, on RSX-11M-PLUS 
system: this routine is simply a RETURN instruction. 
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e Load APR 5 to map the driver 
e Transfer control to the driver 
e Restore the mapping after return from the driver 


e Restore R4 and R5 


Thus, the interrupt vector for a controller serviced by a _ loadable 
driver points to an ICB rather than to the driver. Accordingly, the 
loadable driver does not (and must not) call the SINTSV routine as the 
resident driver does because the S$INTSI routine saves the context on 
behalf of the loadable driver. When it gains control, the loadable 
driver is also partially interruptable as if it had called the S$INTSV 
routine. After it gains control, the loadable driver is exactly like 
the resident driver. (That is, it must also observe the protocols 
established on the system.) 
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Figure 1-3 Interrupt Dispatching for a Loadable Driver 


The ICB allows up to 128 controllers of the same type on ae system. 
The low-order four bits in the PS of the interrupt vector restricts 
the number of controllers to 16. In the ICB, the system maintains a 
controller group number and the PS bits describe the controller number 
within the group. To obtain the real controller number, the Executive 
interrupt service routine adds the controller group number in the ICB 
and the controller number in the PS. (Note that, because ae resident 
driver does not use the ICB mechanism, there can be at most 16 
controllers of one type if the driver is resident. Furthermore, only 
the LOAD command in VMR- supports’ more than 16 controllers of one 


type.) 


The simplest case in handling an interrupt is that in which a 
controller can have only one unit active at any one time. Multiple 
controllers may be active concurrently, yet only one unit per 
controller may be active. When an interrupt occurs, the driver can 
determine the number of the saved controller from information encoded 
in the low-order four bits of the PS. The interrupt service routine 
in the driver uses the number to index a table in the CTB and to 
access the proper unit data and context. 


The more complex case in dispatching an interrupt is that in which a 
controller can have multiple units operating in parallel. This is an 
advanced driver feature called overlapped seek I/O and is described in 
Section 1.4.1. 
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1.3.3 Interrupt Servicing and Fork Process 


A driver (whether resident or loadable) handling an interrupt = and 
operating at the partially interruptable level may need to (1) access 
structures in its data base or (2) call centralized Executive service 
routines which may access structures in the data base. Because a 
driver may have more than one _ process active simultaneously, the 
driver itself may need to access structures in the data base shared 
among separate, unrelated processes. A method must exist to 
coordinate access to the data structures shared among the processes 


and the Executive. 


The mechanism that coordinates access to the shared structures is 
called the fork process. An Executive routine, called fork ($FORK), 
causes the driver to be placed in a queue of processes waiting for 
access to the shared data structures, to run at processor priority 
level (0, and to be completely interruptable.l A driver must’ therefore 
call the fork routine before it calls any other Executive service 
routine (except for SINTSV), or before it accesses any device-specific 
(nonpr vate) structures in its data base. If a driver does not follow 
this protocol, it will corrupt the system data base and will 


eventually cause a system crash. 


A driver that calls the fork routine requests the Executive’ to 
transform it into a fork process. The routine saves a snapshot of the 
proces: in a fork block. The snapshot is the context of the driver 
process--the PC of the process and the contents of R4 and R5. The 
fork b.ock itself resides in the I/O data structure holding the status 
information of the device being serviced (that is, the status control 
block, or SCB). The Executive maintains a list of fork blocks in FIFO 
order. A new fork block is added to the list after the last block in 


the list. 


When the driver calls S$FORK, the CPU priority is lowered to 0, which 
allows other interrupts to be serviced. When there are no more 
pending interrupts (they have either been dismissed or the drivers 
have called S$FORK), the Executive checks to see whether the first 
interrupt preempted a priority 0 Executive process. If a preemption 
occurred, the Executive process is continued from where it was 
interrupted. If no priority level 0 Executive process was 
interrupted, the Executive executes the process at the head of the 
fork list. The Executive restores the saved context of the process 
from the SCB and returns control to the driver at the statement 
immediately following the call to the fork routine. The process is 
unaware that a pause of indeterminate length has elapsed. 


Fork processes thereby are granted FIFO access to the common I/O data 
structures. Once granted such access, a fork process has control of 
the structures until it exits. The protocol guarantees that’ the 
driver process has unrestricted access to shared system data 
Structures. As one fork process exits, the next in the list is 
eligible to run and access the data structures. Thus, the fork 
mechanism allows both controlled access to the common data structures 
and sufficient time to process an interrupt without locking up the 


system. 


1. By convention, drivers may operate at a partially interruptable 
level for no more than 500 microseconds. Some drivers conceivably 
could need more time than this convention allows. Thus, an additional 
reason for the fork mechanism is to preserve the response time of the 
system and not lock out interrupts from lower-priority levels. 
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The status of a fork process lies between an interrupting routine and 
a task requesting system resources. Interrupt routines are run first 
and can be interrupted only by higher-priority interrupts. Processes 
in the fork list run after other system processes either terminate or 
call S$FORK themselves. Because system processes save and restore 
registers, a fork process can uSe all registers. The fork processes 
are completely interruptable. Tasks run only when the fork list is 
empty.1 


The fork mechanism establishes linear, or serial, access to the shared 
data structures. For example, an Executive routine that completes I/0 
processing (SIODON) manipulates the I/O queue to deallocate an I/O 
packet that the driver processed. If multiple processes were allowed 
to alter the queue at random times, the queue pointers could become 
disarranged. Without the fork mechanism, any process could be 
interrupted by a higher-priority process and not be able to complete 
its manipulation. Because the Executive completes a currently active 
fork process before it starts the next fork process in the queue, the 
integrity of the I/0 data structures is maintained if all routines 
that call SIODON run at fork level. 


Between the time that a driver process calls $FORK and the Executive 
Starts the process at fork level, the driver cannot call S$FORK again 
for that same device. If the $FORK routine is called again before the 
first process starts, context stored in the fork block for the first 
fork process is overwritten. However, once a fork process starts, the 
data in the fork block is stale and the process may call $FORK again 
while it is at fork level. If the driver does not ensure against 
unexpected interrupts, it may double fork as described above. As a 
result of the double fork, the driver may either miss an interrupt 
from the device or miss interrupts from several devices. As a further 
consequence, code after the call to $FORK is executed twice for the 
Same context with generally catastrophic results. For example, 
calling $IODON twice for the same I/O packet eventually causes’ the 
system to crash. 


If all drivers adhere to the interrupt protocol, the integrity of the 
I/O data structures is preserved. Thus, when a device interrupt 
occurs while a fork process is executing, the protocol demands’ that 
the service routine handling the interrupt not destroy any of the 
registers. The registers are part of the context of the fork process. 
After the driver dismisses the interrupt or itself becomes a fork 
process, the interrupted fork process can safely resume execution with 
its proper context. If any driver violates the protocol, the 
integrity of the I/O data structures is endangered. (That is, the 
system crashes in mysterious ways.) 


1.3.4 Nonsense Interrupt Entry Points 


All vectors for off-line devices and vectors for which there are no 
devices contain the addresses of Executive nonsense interrupt entry 
points. Code at these special entry points exists to properly dismiss 


1. On a multiprocessor system, the fork list is not necessarily empty 
when the Executive returns control to a task. The Executive processes 


only those fork blocks that are to run on the current processor. To 
ensure that fork blocks remaining in the list are readily processed, 
the Executive running on one processor interrupts (using the 


interprocessor interrupt hardware) any other processor that has fork 
blocks waiting for processing. 
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unexpected interrupts from these devices. If error logging is active, 
any unexpected interrupts are recorded as undefined interrupt errors. 
This feature helps in detecting faulty hardware. 


1.4 ADVANCED DRIVER FEATURES 


Advanced drivers have certain optional and built-in special features. 
This section introduces these features so that you can better 
underszand the structures described in the remainder of the manual. 


1.4.1 Overlapped Seek I/0 


Some disk devices allow multiple device units attached to the same 
controller to execute operations in parallel. This is called 
overla»xped seek suvoport and is a software option designed to take 
advantage of a hardware feature found in most advanced disk drives. 
This feature allows any or all drives attached to the same controller 
to execute a seek function simultaneously. Each unit may perform a 
seek overation sndependent of what another unit may be doing. Only 
one data transfer can occur at any one time. Some types of drives 
allow seek functions to overlap a data transfer function, whereas 
other types do not. 


The increased difficulty for overlapped seek devices stems’ from 
determining whether the controller or the unit generated the 
interrrupt. Most control functions issued to. the drive unit 
(including the positioning commands SEEK and SEARCH) terminate with a 
unit interrupt. The controller reports the physical unit number of 
the interrupting unit in its attention summary register. A controller 
interrupt indicates the termination of a function (usually a data 
transfer command) that changes the controller status from busy to 
ready. Only one unit may issue a data transfer complete notification 
to a particular controller at any one time because only one data 
transf2r can be in progress at any one time. Most hardware defers 
seek termination interrupts until the current data transfer is 
complete. 


To hanjile interrupts for a device that supports overlapped seek 
operations, a device-specific interrupt service routine built into the 
Executive examines the device registers to determine whether’ the 
interrupt was initiated by the controller or the drive unit. Using 
the controller number retrieved from the PS in the interrupt vector, 
the routine forms an index (called the controller index) to use as an 
offset into a table of addresses in a structure (called the controller 
table »r CTB) in the I/O data base. The routine accesses the table to 
determine the address of the I/O data structure of the controller 
(callei the controller request block or KRB) that generated the 
interrupt. Accessing the KRB yields the address of the CSR of that 
controller and having the CSR address allows the routine to examine 
the device registers. 


If the controller itself initiated the interrupt, the routine 
determines the data base structure of the unit that is active. This 
determination is possible because such a controller interrupt relates 
to a termination of a data transfer, and only one such unit can be 
active for a data transfer. A cell in the KRB has the address of the 
data structure describing the active unit (the unit control block or 
UCB). The routine can then determine the address of the driver 
dispatch table and transfer control to the driver. 
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If a device unit initiated the interrupt, the routine retrieves its 
unit number from the Attention Summary Register. Using the physical 
unit number, the routine indexes a table at the end of the KRB_ to 
yield the address of the related UCB. The driver is entered through 
the driver dispatch table. 


1.4.2 Dual-Access Support 


Some devices have multiple-access paths for both control and data 
transfer functions. Such devices are called dual access. A 
dual-access unit is connected to two controllers at one time and may 
be accessed from either controller at the option of the system 
software. Since a single device unit may have only one physical unit 
number, a dual-access unit must have the same unit number for both 
controllers. A dual-access unit may be accessed only from one port at 
a time. The system supports dual-access operation for those devices 
~quipped with the necessary hardware capability. This feature is most 
useful on a multiprocessor system where each access path is to a 
different central processor unit. 


To support dual-access operations, the I/O data structures must 
reflect the existence of alternate controllers. Particularly, the 
driver process context for I/O on a unit can be associated with either 
of two controllers. To decide which controller will provide access to 
the drive unit, the driver must call an Executive routine to request 
access to a particular controller. When the Executive grants access, 
the driver process context for a unit is associated with the assigned 
controller. A driver must have access to the assigned controller 
before actually changing the registers in the I/O page. 


When a driver and a unit are given access to a controller, the 
controller status is set to busy. The unit becomes the device owned 
by the controller for the operation. A controller without an owned 
unit is considered a free controller. By this ownership mechanism, 
controller interrupts are sent to the correct unit for processing. 
After the operation completes, the driver requests the Executive to 
release the controller and thus frees it. 


1.4.3 Delayed Controller Access 


Drivers that support overlapped seeks also must request access to a 
controller before executing a function on an independent unit and must 
release access after completing the _ function. To take maximum 
advantage of simultaneous operation of units on one controller, the 
system delays controller access when the controller is busy. 


The Executive maintains a request queue for the controller. Whenever 
a driver process requestS access to a controller and must wait for 
access to the controller, the Executive places the associated fork 
block in the controller request queue. When a driver releases a 
controller, the Executive automatically grants access to the next 
driver process waiting for access. Precedence is given to positioning 
requests over requests for data transfer. The controller request 
queue thereby provides the means’ for the Executive to synchronize 
access. 


1.4.4 Controller Reassignment and Load Sharing 


Controller assignment for dual-access devices is dynamic. If one port 
(access path) to a device is busy, the system can request access on 


plea 
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the other port. This switching between ports allows the system to 
share the load between the two controllers. 


NOTE 


A dual-access device has both ports 
attached to the same system. DIGITAL 
does not support systems loosely coupled 
through a peripheral. 


The system also maintains an I/O count for each controller to 
deterrine how busy it is. If one controller is not as busy as the 
other, the system can queue the access requests to the less’ busy 
controller. Whenever load sharing is done on a dual-access unit, the 
Executive makes any reassignment necessary before actually requesting 
access to the controller. 


1.4.5 Common Interrupt Dispatching 


To handle interrupts from a controller that supports more than one 
type of device, the Executive uses a mechanism called common interrupt 
dispatching. The RH70 MASSBUS controller can have different types of 
devices (RPO4, RPO5, and RPO6 moving head disks; RM0O2, RMO3, RMOS, 
moving head disks; RM80 and RPO7 fixed media disks; ML11 
non-rotating memory; RS0O3 and RSO4 fixed head disks; and TE16, TU45, 
and TU77 magnetic tape drives) connected to the same type of 
controller. Interrupt dispatching for such devices is more difficult 
than for standard interrupt devices because associated with one set of 
interrupt vectors are multiple drivers. To dispatch interrupts, 
therefore, a routine in the Executive must intervene. Figure 1-4 
shows an example of common interrupt dispatching. 


DB 
Driver 


Common 


Interrupt 

Dispatch 

Routine 
(SRHALT) 


RH70 Interrupt 


Vectors 
ZK-248-81 


Figure 1-4 Interrupt Dispatching for Common Interrupt Devices 


The vectors for such controllers point to a common interrupt 
dispatching routine in the Executive module DVINT. This common 
routine avoids having to duplicate code in drivers. This routine, in 
essence acting like an RH70 controller driver or a sophisticated ICB, 
determines which driver will receive control upon an interrupt. 
Operating like the routine that handles interrupts for overlapped seek 
devices, this routine determines the type of device that interrupted 
and dispatches to the proper driver. 
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1.4.6 Subcontroller Devices 


Certain devices have 2-level controllers, such aS magtapes, where a 
TMO03 connects to an RH70 MASSBUS controller and also connects to TE16 
magtape drives. In such an arrangement, the TMO3 is a subcontroller, 
or master unit, that controls slave units; a register in the master 
unit reports the number of the slave unit that generates an interrupt. 


A subcontroller is associated with a data structure called a 
subcontroller request block (KRB1) that serializes access to the 
Subcontroller. Therefore, a driver must request and receive access to 
both the subcontroller and the controller for a unit before executing 
any operations. The KRB1 is a subset of the KRB and every unit on the 
subcontroller points to the KRB1 of the subcontroller to which it is 
attached. 


1.4.7 Full Duplex Input/Output 


In certain circumstances it may be necessary for a driver to handle 
more than one I/O request on a unit at the same time. Typically a 
driver processes only one I/O packet per unit at any one time. In 
normal operation the driver calls the Executive routine $GTPKT to get 
an I/O packet to process. When SGTPKT returns an I/O packet, it marks 
the device busy and does not allow additional I/O until the first I/0 
activity completes. Therefore, only one I/O process can be in 
Progress at the same time on a device. Full duplex operation allows 
more than one I/O process to be in progress on a device at the same 
time. 


To allow full duplex operation, the $GTPKT routine has a special entry 
point called $GSPKT. A driver calling $GSPKT specifies an acceptance 
routine, to which $GSPKT returns control when an eligible packet is 
found. The acceptance routine determines whether to accept or reject 
the packet. The criteria that the acceptance routine applies could be 
that a write request is accepted if a write has just completed or that 
a read request is accepted if a read has just completed. If the 
routine rejects the packet, it indicates so to $GSPKT, which continues 
to search for another packet. If the acceptance routine accepts’ the 
packet, SGSPKT dequeues the packet and passes it to the driver but 
does not modify U.BUF and U.CNT in the unit control block (UCB) nor 
does it mark the device busy. As ae result, during full duplex 
operation the device appears idle even while it is processing an I/0 
request. 


To complete an I/O request under full duplex operation, the driver 
calls the SIOFIN routine rather than the SIOALT or S$IODON routine. 
SIOFIN does final processing without making the device look idle, as 
SIOALT and SIODON attempt to do. In full duplex operation, a unit 
will always appear idle to the system and the driver acceptance 
routine will determine whether the device can handle an I/O request. 


A driver handling full duplex operations requires augmented data base 
structures. The conventional data base structures are defined for 
only one I/O request in progress per unit. Because the driver has to 
keep more information concerning a unit that allows two I/O requests 
in progress, you may have to alter the UCB and other data base 
Structures to provide additional offsets. The DIGITAL-supplied full 
duplex terminal driver not only uses a lengthened UCB and a 
nonstandard SCB, but also connects’ to a dynamically allocated UCB 
extension when the device is configured on-line. 


A driver that handles full duplex operations provides a_ specific 


example of software that handles concurrent I/O for individual units. 
Some devices, such as the DIGITAL-supplied LPA11-K 
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microprocessor-based laboratory subsystem, can handle a number of 
simultaneously active I/O requests. The software to handle such 
concurrent I/O may require augmented driver data base structures so 
that the context of each I/0 process remains distinct and 
controllable. The driver for the LPA11-K relies on an extended user 
control block (UCB) to preserve the context of a maximum of eight 
Simulteneously active I/O processes. User-written software for such a 
device must properly synchronize fork processing to prevent 
substituting the I/O context of one process for that of another. 
Moreover, the SGSPKT routine also might be used as described above to 
make a unit appear idle when it is busy. 


1.4.8 Buffered Input and Output 


Typically, data for input and output requests are transferred directly 
to and from task memory. To allow the successful transfer of data, 


the task cannot be checkpointed until the transfer is complete. For 
most high-speed devices, the transfer occurs quickly enough so that a 
task does not occupy memory for too long ae time. For slow-speed 


devices, however, some mechanism must be available tu avoid binding 
memory to a task for too long a time while the task is performing I/O. 


Using the routines $TSTBF, SINIBF, and SQUEBF in the Executive module 
IOSUB, a driver can execute an I/O request for a slow-speed device and 
allow the task to be checkpointed while the request is in progress. 
To perform the I/O request, the driver buffers the data in memory 
allocated to the driver while the task is checkpointed and the I/0 
request is in progress. 


To test. whether a task is in a proper state to initiate I/0 buffering, 
the driver calls the STSTBF routine and passes it the address of the 
I/O packet. By extracting the address of the task control block (TCB) 
from the I/O packet, S$TSTBF can examine various task attributes. For 
example, if the task is checkpointable, buffered I/O can be performed. 
STSTBF returns to the driver and indicates whether buffered I/O can be 
performed. 


If buffered I/0 can be performed, the driver performs two operations. 


First, it establishes the buffering conditions. For an output 
request, it copies the task buffers to dynamically allocated pool 
space. For an input request, it allocates sufficient pool space to 
receive the incoming data. Second, the driver calls the SINIBF 


routine to initiate the I/O buffering. SINIBF decrements the task I/0 
count, increments the task's buffered I/O count in T.TIO, and releases 
the tzesk for checkpointing and shuffling. If the task is currently 
blockec, the task state is transformed into a "“stopfor" state until 
the task is unblocked, buffered I/O completes, or both. Checkpointing 
the task is subject to the normal requirements of an active or 
"stopfcer" state as described in the RSX-11M/M-PLUS Executive Reference 
Manual. 


After the driver transfers the data, it calls the S$QUEBF routine to 
queue the buffered I/0 for completion. SQUEBF sets up a kernel 
asynchronous system trap (AST) for the buffered I/0 request and if 
necessery, unstops the task. When the task is active again, a routine 
in the Executive module SYSXT notices the outstanding AST and 
processes it. (If the request is for input, the routine copies the 
buffered data to task memory.) This mechanism occurs transparently to 
the task, thus the name kernel AST. The routine then calls the driver 
to deallocate the buffer from pool. SIOFIN completes the processing. 
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1.4.9 I/0 Queue Optimization 


Without I/O queue optimization, the operating system groups input and 
output requests in the queue by highest priority on a first-in, 
first-out basis. The first request at the highest priority appears 
first in the queue and is processed first. Other requests within that 
Priority are then processed sequentially until the last request at 
that priority is serviced. 


With I/O queue optimization, however, the next I/0 request at the 
highest priority is not necessarily the next sequential request to be 
processed. I/0 queue optimization allows the queue to be scanned, and 
each request to be examined. The I/O request, according to the method 
of optimization then in effect, is the next one dequeued and passed to 
the I/O driver for processing. The highest priority requests are 
still serviced first; however, throughpucz is improved by the 
reordering of requests within a priority. 


There are three methods of I/O queue optimization available: 
@e Nearest Cylinder 
e Elevator 


e Cylinder Scan 


The Nearest Cylinder method processes the I/O request that is closest 
to the one at which the disk head is currently positioned. The 
Elevator method processes requests as the disk head moves from the 
perimeter to the innermost track of the disk. Once the disk head 
reaches the innermost track, the direction iS reversed and requests 
are processed along the disk as the head moves back to the perimeter. 
The Cylinder Scan method operates similar to the Elevator method, 
except requests are only processed as the disk head moves from the 
perimeter to the innermost track. Once at the innermost track, the 
disk head returns to the perimeter and begins processing new requests. 


The method you choose for your system is dependent upon the _ I/0 
processing requirement of your application, the frequency with which 
tasks access certain data areas on the disk, and the physical location 
of data on the disk. Refer to the RSX-11M/M-PLUS System Management 
Guide for information on selecting I/O queue optimization methods. 


Before an I/O request can be queued to the driver, all three queue 
optimization methods require the starting cylinder number of the I/0 
request. To find the cylinder number, the logical block number  (LBN) 
of each I/O request is converted to cylinder, track, and sector form. 
The routine $DRQRQ in the Executive module DRSUB’ begins this 
conversion. Because the cylinder, track, and sector form is specific 
to the device geometry, this conversion must be completed by a 
separate routine in the driver. The routine SDRORQ locates the 
conversion routine in the driver through offset D.VCHK in the driver 
dispatch table. 


The routine S$DRQRQ calls the conversion routine for all I/O requests. 
However, if the functions are not logical transfer functions, such as 
ACP functions or Attach and Detach operations, the conversion routine 
does not complete the conversion, but rather returns to $DRQRQ. 


Drivers without queue optimization call the routine $BLKCK in the 
Executive module MDSUB to check the limits of the I/O request. If 
SBLKCK locates an error, the routine SIOALT in the Executive module 
IOSUB is called for the I/O reque:t and the driver is returned to the 
initiation entry point. If you chose queue optimization, a return to 
the initiation entry point is not desirable because the necessary 
functions of $DRQRQ will not be completed. Therefore, your completion 
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routine must call the routine S$BLKC2 in the Executive module MDSUB 
instead of $SBLKCK to ensure the correct return to $DRQRQ if an error 
is de:ected. 


The routine S$GTPKT in the Executive module IOSUB performs the actual 
optim. zation. The driver calls the Executive routine $GTPKT for an 
I/O request to process. SGTPKT scans the queue of I/0 packets’ to 
select. those of the highest priority. The routine then chooses the 
correct packet within that priority based on the optimization method 
currently in effect, dequeues that packet, and returns control to the 
driver to process that I/O request. 


1.5 DISTRIBUTED I/0 


On a multiprocessor system, a task may issue an I/O request to any 
device on any processor. The Executive must’ be responsible for 
distributing the I/O request to the correct processor. To ascertain 
to which processor a device is attached and to have the driver execute 
on tke correct processor, the Executive must perform some 
processor-specific functions. The following sections introduce the 
data structure and the processing routines used by the Executive for 
processor-specific functions. 


1.5.1  UNIBUS Run Mask 


To help describe devices attached to a processor, the software relies 
on a concept called UNIBUS run. A UNIBUS run consists of a group of 
distinct devices, all of which are electrically connected to the same 
UNIBUS and are not separated by any bus reconfiguration devices. Each 
UNIBUS run is attached to the same processor at the same time because 
of the way the devices are physically attached to the UNIBUS. 
(Devices attached to a MASSBUS of a processor are also on _ the 
Processor's UNIBUS run.) The UNIBUS run, then, is the smallest 
fragment of a particular UNIBUS capable of being switched (or not 
switched) between processors. 


Essential to understanding UNIBUS runs is the concept of a switched 
bus. A switched bus is a portion of a UNIBUS that can be physically 
connected to one of multiple UNIBUSes. A device on the UNIBUS, called 
the DTO7 UNIBUS switch, controls the connection and allows a switched 
bus to be connected to any one of a maximum of four UNIBUSes. Any 
UNIBUS device or devices except a procesSor or another bus switch may 
be coniected to a switched bus. Moreover, because of the electrical 
delay associated with the bus switch, some high-speed devices (such as 
the DM*°-11) cannot be on a switched bus. 


In a miltiprocessor system, the DT07 allows the switched bus to _ be 
physically switched from the UNIBUS of one processor to the UNIBUS of 
anothe- processor. When the switch is connected to a particular 
Pproces:3or's UNIBUS, all peripherals on the switched bus operate as if 
they were permanently connected to that UNIBUS. By means of 
reconf guration software, a switched bus can be disconnected from one 
UNIBUS and be available for connection to another processor's UNIBUS. 
Because a user task can direct an I/O request to any device on the 
system. the Executive must be able to perform the operation on the 
Specif:c processor to which the device is connected. 


A UNIBUS run is represented in a cell called a UNIBUS run mask (or 
URM) . The URM is a 16-bit word containing a bit for every possible 
UNIBUS run. UNIBUS runs are numbered from 0 to 15, and the system is 
restricted to a maximum of 16 UNIBUS runs. There are four UNIBUS runs 
reserved for the maximum of four processors. The numbering allows a 
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maximum of 12 switched buses. However, a Switched UNIBUS cannot be 
connected to another switched UNIBUS. A primary UNIBUS run would 
contain a processor, its UNIBUS, and the peripherals directly attached 
to its UNIBUS; and a secondary run would consist of a switched bus 
and the devices attached to it. 


In the I/O data structures for each controller in the multiprocessor 
system is an associated UNIBUS run mask. The bit set in the URM 
defines the UNIBUS run to which the controller is attached. In the 
Executive, there is a table of connectivity masks, one UNIBUS run mask 
for each processor in the system. The table represents the UNIBUS 
runs to which each processor is attached. A bit set in the table mask 
word for a processor indicates that the UNIBUS run is currently 
associated with that processor. 


To ascertain whether a controller is attached to the current 
processor, the Executive compares the controller URM with the mask for 
the processor in the connectivity table. If the same bit is set in 
both words, the controller is attached to the current processor. If a 
bus is switched from one processor to another, the system need alter 
only the connectivity masks of the processors affected. 


1.5.2 Conditional Fork 


The conditional fork routine ($CFORK) is the method by which the 
Executive distributes I/O requests to devices connected to another 
processor. In a multiprocessor system, peripheral devices are 
generally accessible to only one UNIBUS run. Devices that do have 
dual-access capability are not necessarily accessible from every 
UNIBUS. The Executive ensures that, when a driver accesses a 
controller, the driver process executes under control of the processor 
in whose I/O space the controller registers reside. An exception is 
the Executive passing control to a driver for special processing of an 
I/O packet. In this case, the driver is responsible for ensuring that 
the process executes on the correct CPU. See the discussion of the 
UC.QUE bit in Section 4.4.4. 


The conditional fork routine is necessary because the system allows 
Processors to remain anonymous as far as task execution is concerned. 
The system does not restrict execution of a user task to the processor 
associated with a device to which the task directs I/O. Basically it 
is the driver processes that need to execute on specific processors. 


1.5.3 Processor-Specific Functions 


When the Executive calls a driver to initiate I/O, the driver may not 
be executing on the processor associated with the device unit to which 
I/O is directed. When the driver requests an I/O packet to process, 
the Executive must enSure that the driver executes on the correct 
Processor because the driver may access the I/O page. Therefore, the 
Executive routine (SGTPKT) that dequeues an I/O packet for the driver 
performs a conditional fork. A cell in the fork block for the device 
unit contains a UNIBUS run mask that defines the processor to which 
the unit's controller is attached. The conditional fork routine 
accesses this cell to ascertain what action to take. 


The URM of the device to which the I/O request is directed therefore 
determines whether the driver may execute on the current processor. 
If the URM of the device intersects the current processor URM, the 
conditional fork routine returns and the I/0 packet is immediately 
passed to the driver. The driver then normally proceeds to start the 
proper I/O function. If execution must be continued on another 
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processior, the conditional fork routine performs a fork (that is, 
calls the S$FORK routine). The driver has no indication that it has 
become a fork process (that is, the action is transparent to the 


driver’. 


To enstire that the driver executes on the correct processor, the fork 


routine does two operations. First, it creates and queues a fork 
block tor the processor on which the driver must execute. Second, it 
returns to the driver in such a manner as to force the driver to 


dismiss itself. As soon as possible, the fork processor restarts the 
driver process executing on the appropriate processor. 


For devices that do not have an assigned controller, the system may 
defer determining whether the driver executes on the current 
processor. Therefore, for overlapped seek and dual-access devices, 
the conditional fork routine is entered after the Executive routine 
that assigns the controller. 


1.6 OVERVIEW OF INCORPORATING A USER-WRITTEN DRIVER INTO RSX-11M-PLUS 


How yot! incorporate a user-written driver into the system depends 
mainly on whether you make your driver loadable or resident. If your 
driver is loadable, its data base can be either loadable or resident. 
Tf your driver is resident, both its data base and its code are 
resident. Thus, because you build the Executive image during system 
generation, you can include any resident driver elements in the 
Execut ve image only during system generation. If your driver is 
loadab.e and has a loadable data base, you can incorporate it at any 
time ater you build the Executive under which the driver will run. 


During system generation, you answer questions concerning the types 
and quantity of peripheral devices on your system. Based on your 
answer:, the system generation software creates the device data base 


source files. The file SYSTB.MAC contains the data base definitions 
for al.. the DIGITAL-supplied devices that were generated with resident 
data bases. The files xxTAB.MAC, where xx is the device mnemonic, 
contain the data base definitions for each of the DIGITAL-supplied 
device:s that were generated with loadable data bases. The files 
XXDRV.MAC, where xx is the device mnemonic, contain the driver code to 
Support: the devices. The system generation software assembles and 


task builds these modules. The resident driver and data base modules 
are 1 nked into and become a permanent part of the Executive. The 
loadab.e driver and data base modules are task built separately for 
loading into memory after the Executive has been built. 


A priv leged system task called LOAD is responsible for loading into 
memory a driver that is not resident. LOAD creates the necessary 
interrupt control blocks (ICBs) for accessing a driver and establishes 
the lnkage between the data base structures in the system device 
tables and the driver code being loaded. Another system task called 
CON initializes the interrupt vectors to point to the ICBs and 
actual’ y places the devices on-line. CON can also change the vector 


and CSR address assignments in a device's data base. Another 
privileged system task called UNLOAD can remove a loadable driver from 
memory . (Although UNLOAD removes a loadable driver, it does not 


remove a loadable data base.) 


To incorporate a user-written driver into RSX-11M-PLUS, you first 
create two modules, one in which you define the data base and the 
other -n which you include the driver code itself. You then must 
integrate your driver data base and driver code modules into the 
system device tables. If your data base is resident, the linkages 
that -vour data base module must satisfy are: (1) the link of the 
contro. ler table (CTB) list; and (2) the link of the device control 
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block (DCB) list. The linkage for the driver code connects the DCB 
for the device that your driver supports to the driver dispatch table 
(DDT). If your driver and data base are loadable, you must supply in 
your code symbols and labels that LOAD needs. Your device interrupt 
vectors are initialized and the devices are placed on-line by CON. 


Because the data base for a loadable driver can be loadable, the LOAD 
task also loads a data base. When you load a driver, LOAD checks to 
see whether a data base is resident for the type of device whose 
driver is being loaded. If a data base is not resident, LOAD reads 
the driver symbol definition file to find the start and end of the 
data base in the driver image. (Thus, if your driver data base is to 
be loadable, you must have defined its start and end in the data base 
source code.) Knowing the start and end, LOAD reads the data base from 
the driver image. LOAD places the data base in the system pool. so 
that it resides in Executive address space, accordingly relocates 
pointers and links within the data base to be valid Executive 
addresses, and also connects the CTB and DCB(s) in the data base to 
the system device tables. Moreover, so that the system device tables 
are not corrupted by an incorrect data base, LOAD performs many 
consistency and validity checks on the data base being loaded. 


If your driver is loadable and has a loadable data base, you will 
build (1) a loadable image containing the driver code module followed 
by the driver data base module and (2) a symbol definition file on 
which LOAD depends to find critical data base and driver locations. 
You will link the driver image to the Executive under which the driver 
will run. However, the driver image will be separate from the 
Executive image. LOAD is responsible for loading both your driver 
data base and driver code, for connecting the data base to the system 
device tables, and for connecting your driver code to the data base. 


If your driver is loadable but has a resident data base, you will have 
to perform a system generation and build the Executive under which the 
driver will run to link your driver data base module(s) into the 
system device tables. This ‘operation makes your driver data base 
resident with the system device tables. You will also build (1) a 
loadable image containing the driver code and (2) a symbol definition 
file which LOAD will use to locate the driver dispatch table. LOAD is 
responsible for loading your driver code and for connecting your 
driver code to the data base that is resident with the system device 
tables. 


If your driver is resident, you will have to perform a system 
generation and build the Executive to link the driver data base into 
the system device tables and to include the driver code in the 
Executive image. 


Whatever type your driver is, you will use the CON task to initialize 
the device interrupt vectors and place the devices on-line. 


Because LOAD provides consistency and validity checks on a data base 
being loaded, DIGITAL recommends that you make your driver and its 
data base loadable. (Additional rationale for making your driver 
fully loadable is given in Section 1.7.) Furthermore, with a loadable 
driver and loadable data base, you can more easily modify your driver 
and its data base. You need not rebuild your Executive and privileged 
tasks. To change the driver code, you need only build a new driver 
image, unload the current version, and reload the new version. To 
change the driver data base, you must build a new driver image (which 
incorporates the modified data base module), rebootstrap your system, 
and load the new driver which causes the modified data base to be 
loaded. (You must bootstrap your system to change the data base 
because UNLOAD does not unload a data base, and because LOAD does not 
load a data base for a driver if one is currently loaded for that 
driver.) 
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Using a loadable driver with a loadable data base saves work in the 
long term. During debugging, data base inconsistencies are likely to 
be caught by LOAD. Thus, you prevent many such errors from later 
creating system problems. 


A resident driver or a loadable driver with a resident data base is 
more difficult to debug and to modify. LOAD does’ not perform 
consistency and validity checks on a resident data base. Thus, a 
valuable debugging aid is not available. Moreover, to modify such 
drivers, you must rebuild the Executive, which generally implies 
rebuilding the privileged tasks. 


1.7 SPR SUPPORT 


The capability to incorporate a user-written driver into your system 
is a supported feature of RSX-11M-PLUS. Because a user-written driver 
is considered a system modification, DIGITAL may not support’ the 
systen that results after you incorporate your driver. Being a part 
of the Executive, your driver can subtly corrupt it. Therefore, 
DIGITAL cannot guarantee support which entails debugging usSer-written 
drivers. 


Fixing a problem in a system is largely a matter of being able _ to 
reproduce the problem reliably. If a problem on your system can be 
shown to have no relation to your driver and DIGITAL can reproduce the 
problem, SPR support can be provided. A good reason for using a 
loadable driver with a loadable data base is that you can more easily 
attain an unmodified system by not loading your driver and its data 
base. You can then reproduce a suspected problem in an _ unmodified 
system and can submit an SPR that DIGITAL can answer. Therefore, your 
attempting to recreate a suspected problem on your system without your 
driver and its data base saves both you and DIGITAL time in answering 
the SPR. 


CHAPTER 2 


DEVICE DRIVER I/O STRUCTURES 


This chapter deals mainly with structures at the block level, their 
relationship to the hardware configuration and _ functionality 
Supported, and their relationships to each other. The precise 
description of each structure is given in Chapter 4. 


2.1 I/O STRUCTURES 


The main elements in the driver I/O environment essentially define the 
logical and physical characteristics of the supported hardware and 
establish the links and connections by which routines can access’ and 
manipulate driver data. The following subsections describe the 
control blocks that a driver data base module defines, and exphain in 
general terms the purposes for each block. 


2.1.1 Controller Table (CTB) 


A controller table defines a unique controller type on the system. A 
CTB must exist for each physical controller type. All controller 
tables are linked together, in a list, with the head of the list 
SCTLST in the Executive common. area. The list of the controller 
tables is one of the threads through the system data base to provide 
access to all device-related data. The link in the last CTB in the 
list has a value of zero. 


Associated with each CTB is a 2-character ASCII controller name which 
must be unique throughout the system. This unique name allows the 
Executive to find the correct CTB for the controller’ type. For 
example, the RH11/70 controller has the name RH instead of DB, DS, DR, 
or MM. 


A CTB is a static structure created during system generation. Any 
user-written driver data base, therefore, must have its own CTB. The 
user-created controller table must also be linked into the system CTB 
List. 


A CTB has generic status information, links, and pointers to. other 
Structures on the system. The table of KRB addresses in the CTB is 
the means by which the Executive handles interrupts for the controller 
type and dispatches to the correct driver routine. 


2.1.2 Controller Request Block (KRB) 


The controller request block is the means by which the Executive 
maintains controller- or hardware-specific information and accesses 
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the correct information for a unit which its associated controller 
owns. One KRB exists for each device controller in the configuration. 
It stores such data as vector and CSR location, status, and UNIBUS run 
mask. 


In a configuration where a device has only one access path to a 
controller and the controller allows only one operation at a time, the 
KRB is combined with another structure called the status control block 
(SCB). (The SCB holds context for a unit while an operation is in 
progress.) Because only one access path is possible in such a 
configuration, unit context is always associated with the same 
controller. Moreover, because only one operation is possible at a 
time, the same context storage area can be used for all units attached 
to the controller. Thus, in a conventional driver operating 
environnent, the context storage is merely an extension of the 
controller request block. 


In a configuration where multiple operations in parallel on the = same 
controller are possible, the controller context is separate from each 
independent unit context. Therefore, each unit capable of operating 
independently on a controller has the context of the current I/0 
operation stored in an SCB separate from the controller KRB. In such 
an operating environment, any unit can access the controller while 
other operations are pending, but only one unit can have access at a 
time. The KRB, then, indicates which unit owns the controller for the 
current operation, and synchronizes access among driver processes. on 
the same controller. 


Where multiple operations in parallel are allowed on a controller, 
there must be some way to delay access to the controller when it is 
busy. Therefore, in the KRB the Executive holds the head of a list of 
access requests called the controller request queue. The list 
contains fork blocks for driver processes awaiting controller access. 
The queue is the means by which the Executive serializes access to the 
controller. 


When a controller allows parallel operations, the software must have a 
means of determining which of several units generated an interrupt. 
The KRE, therefore, contains a table of addresses which associate the 
controller with all the units connected to it. This table, indexed by 
physical unit number, must appear if the controller in question 
supports overlapped seek operations. When a device has multiple- 
access paths, the controller-specific information in the kKRB is 
separate from each independent unit context. In a situation where a 
device accesses alternate controllers, a driver must request’ the 
Executive to assign the unit to a specific controller. The unit 
assignment involves temporarily associating unit context with the KRB 
of the specific controller. The SCB, then, holds’ information 
connecting it to the KRB of the currently assigned controller. 


The KRE also holds the configuration status of the controlier. If the 
KRB indicates that the controller is off-line, no activity can take 
place on any unit connected to the controller. 


2.1.3 Device Control Block (DCB) 


The device control block describes the static characteristics of a 
device type and of units associated with a certain device type. The 
DCB is the means of access to the driver dispatch table and thus to 
the driver. At least one DCB exists for each logical type of device 
on a system. There may be more than one DCB for a device type. For 
example, there are two device control blocks for the device TT: ona 
system that supports terminals connected by both DL11 and D211 
interfaces. 
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A cell in each device control block forms a link in a forward-linked 
list, with the head of the list starting in a cell ($DEVHD) in the 
Executive common area. This list, as with the CTB list, iS a main 
thread through the system data structures to device-related data. The 
link in the last DCB in the list has a value of zero. 


The static data in the DCB gives such information as the generic 
device name, unit quantity and links to individual unit data, the 
address of the driver dispatch table, and types of I/0 functions 
Supported by the driver. Typically, the Executive QIO directive 
Processing code and not the driver code accesses the DCB. 


2.1.4 Unit Control Block (UCB) 


The unit control block holds much of the static information about an 
individual device unit and contains a few dynamic parameters. 
Although unit control blocks need not be any prescribed length for 
different devices, all unit control blocks for the same device type 
must be of equal length. (The UCB length is stored in the device 
control block.) This condition allows the UCB to contain varying 
amounts of unit- and device-independent data for different types of 
devices. 


A UCB, one of which exists for each device unit, enables a driver to 
access most of the other structures in the I/O environment. A UCB 
provides access to most of the dynamic data associated with I/0 
operations. Given the address of a UCB, a driver may readily find 
most of the other data structures in which it is interested because 
the proper links exist. Because of this access information, the UCB 
is a key control block in the driver I/O structure. 


The static data in the UCB includes pointers to other I/O structures, 
definitions of unit control bits which regulate directive processing, 
definitions of unit status bits which describe operational conditions, 


and definitions of unit- and device-dependent characteristics and 
Storage cells. 


Data in the UCB is accessed and modified by botn the Executive and the 
driver. 


2.1.5 Status Control Block (SCB) 


The status control block holds driver context for operations on a 
device unit. In the SCB are stored such data as the pointer to the 
head of the queue of input/output requests; the link to the fork 
blocks queued for the unit; the fork process context; timeout, unit 
Status, and error logging information; and the address for the 
controller request block (KRB) representing the device controller (if 
the device has a controller). 


The Executive accesses the SCB to set up an I/O request, to store 
context while a request is in progress, and to post results and 
Status. When the driver accesses the SCB, it is usually for read 


access only. 


The number of status control blocks depends on the processing support 
in the Executive. If the controller itself cannot handle parallel 
operations, only one SCB is needed for each controller. In such a 
case, a controller can have only one unit processing a command at one 
time, and there is no need to store context for more than one unit at 
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a time. There is also no need for a physically separate controller 
request block (KRB) to separate generic data from unit context. 
Therefore, the driver data base contains the required KRB cells in the 
Status control block. 


If the controller allows parallel operations and the Executive 
Supports this feature, there must be one SCB to store context for each 
unit capable of operating independently on the controller. In such a 
configuration, a cell in each SCB points to the KRB of the controller 


to which the units are connected. 


2.2 DRIVER DISPATCH TABLE (DDT) 
The driver dispatch tablel contains the entry points to and the 
interrupt entry addresses for the driver. An entry point is the 
location at which the Executive calls the driver to perform a specific 
function. An interrupt entry address is a location to which the 
central processor or the Executive transfers control within the driver 
for servicing hardware interrupts. The pointer to the interrupt entry 
address resides either in an interrupt control block if the driver is 
loadadle or in the device interrupt vector in the system common area 
of the Executive if the driver is resident. 
Every driver has four conventional entry points as follows: 

® I/0 initiation 

2® cancel I/0 

® device timeout 

® device powerfail 


Two more entry points are added for controller and unit on-line = and 
off-line status changes: 


# KRB status change 
# UCB status change 


For many devices, these status change entry points are merely a return 
to the Executive calling routine. 


There are two additional entry points that have been added for advance 
driver features: 


« Deallocate buffers and next command (FDX TTDRV) 


# Address checking and conversion (queue optimization disk 
drivers) 


l. The DDT is not a structure in the strict sense of the word because 
it is defined in the instruction part of the driver code. However, 
because it contains addresses for dispatching code, it is included in 
the data structure description. 
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2.2.1 I/0 Initiation 


The Executive transfers control to this entry point to inform the 
driver that work for it is waiting to be done. To make work for the 
driver, the Executive performs predriver-initiation processing. 
(Predriver initiation is described in Chapter 3). If, at the end of 
predriver processing, the Executive has I/O packets queued for the 
driver, it calls the driver at this entry point. 


When the driver gets control at its I/O initiation entry point, R5 
contains the address of the UCB for the unit on which the request is 
to be processed. To establish access to the I/O packet, the driver 
calls an Executive routine that either returns information in 
registers concerning both the packet to be processed and the 
associated data in order to gain access to the data structuresl or 
causes the driver to dismiss itself. (There may be no packet to 
process or the driver may already be busy.) 


Once control is returned to a driver and there iS a request to 
process, the driver must extract the information from the registers, 
establish data within the control blocks, and process the request. 
This means that the driver proceeds with an I/O request until it sets 
the GO bit on the device, which physically initiates the I/0 
operation. 


Typically a driver is called at this entry point when there is a 
packet in the I/O queue. However, a driver can be called before a 
packet is placed in the I/O queue. Refer to the description of the 
U.CTL control flag UC.QUE in Section 4.4.4 for information on queueing 
an I/O packet to the driver. 


2.2.2 Cancel I/0 


To terminate an in-progress I/O operation, the system flushes the I/O 
queue and calls the driver at this entry. There are many situations 
in which a task must terminate I/O. When such a termination becomes 
necessary, a task issues an Executive request and the Executive relays 
the request to the driver by calling it at this entry point. 


The driver is responsible for checking that the I/0 operation 
in-progress was issued from the task that is forcing the termination, 
and for completing or terminating the operation before returning to 
the caller. 


Typically, a driver is called at this entry point only when an I/O 


operation is in progress. A driver can be called even if the unit 
specified is not busy. Refer to the description of the U.CTL control 
flag UC.KIL in Section 4.4.4 for information on _ unconditional 


cancelling of I/O. 


2.2.3 Device Timeout 


When a driver initiates an I/O operation, it can establish a timeout 
count. If the operation fails to complete within the specified 
interval, the Executive notes the lapse and calls the driver at this 


1. The $GTPKT routine, which gets a packet for the driver to process, 
is described in Chapter 7. 
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entry point. Using this facility, a driver can wait for an interrupt 
but need not hang up if the interrupt never occurs. Thus, no driver 
should ever stall on a request because a hardware failure prevented an 
expected interrupt from happening. 


2.2.4 Device Power Failure 


The Executive calls the power failure entry point when power is 
restored after a failure any time the controller is busy (that is, 
when I/0 is in progress). Typically, a driver responds to a = power 
failure in the same manner it responds to a timeout. In Such cases, 
the power failure entry point may simply be a return to the caller 
because recovery will occur by means of the timeout entry point. The 
driver is called for both controller and unit power failure unless the 
driver is associated with a common interrupt controller. For common 
interrupt controllers, the driver is called at this entry point only 
for unit power failure and is called at a special entry defined in the 
common interrupt table for controller power failure. 


A driver can be called when power is restored regardless of the 
existence of an outstanding I/O operation. Refer to the description 
of the U.CTL control flag UC.PWF in Section 4.4.4 for information on 
unconditional call on power failure. 


2.2.5 Controller and Unit Status Change 


Two entry points are required for configuration status changes of the 
controller and units. The Executive enters one entry point to put the 
controller on-line and take it off-line. The other entry point, 
Called once for each unit whose status changes, is for putting units 
on-line and taking them off-line. The driver must show’ successful 
completion of the on-line or off-line request or the Executive will 
not effect the status change. The driver has 60 seconds to perform 
whatever synchronization it requires before returning to the 
Executive. In most cases, however, the driver will return 
immediately. 


2.2.6 Device Interrupt Addresses 


Control passes to an interrupt address when a device, previously 
initiated by the driver, completes an I/O operation and causes an 
interrupt in the central processor. A device may have associated with 
it more than one interrupt entry. For example, a full duplex device 
such aS a terminal will have two interrupt addresses. The interrupt 
entry differs from an entry point in that the connections between the 
device and the driver is more direct--the Executive is not involved. 


The interrupt addresses are arranged in a block in the DDT. The 
arrangement is general enough to support multicontroller drivers such 
as the terminal driver. The block defines the address or addresses to 
include in the vector for the driver. There is no restriction on the 
number of vectors each controller has, and the number of vectors is 
implied by the number of addresses in the interrupt address block. 


2.3 TYPICAL CONTROL RELATIONSHIPS 


This section presents different arrangements of the control structures 
that are found in RSX-11M-PLUS. The section concentrates on the 
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relationships among device control, unit control, status control, and 
controller request blocks and controller tables based on hardware and 
functions supported. Descriptions of the detailed contents of the 
Structures is left to Chapter 4, where the coding requirements are 
presented. Some of the arrangements are not conventional but are 
shown to convey the flexibility you can find in a system. Section 2.4 
shows how such arrangements fit into the overall system I/O data 
structure. 


The arrangements described in this section illustrate the strategy in 
offering a flexible I/O data structure. There need be only one 
controller table for each controller type. Multiple-device control 
blocks for a single device type reflect the capability to handle 
varying characteristics. The existence of one or more status’ control 
blocks depends on the degree of parallelism possible: one SCB for 
each controller servicing several units (no parallelism); or one for 
each device unit combination on the same controller (unit operation in 
parallel). 


The I/O data structure reflects the hardware configuration that the 
data structures describe. The flexibility in the data structure 
arrangements provide flexibility in configuring I/0 devices. The 
information density in the structures themselves reduces the coding 
requirements for the associated drivers. 


2.3.1 Multiple Units per Controller, Serial Unit Operation 


A typical arrangement of structures for a user-written driver is shown 
in Figure 2-1. The arrangement could represent an RKO5J controller 
with two RKOS drives attached. A single controller table (CTB) 
defines the existence of the controller type on the system. One 
device control block (DCB) establishes the characteristics for the 
type of device running on the controller. 


The status control block (SCB) and controller request block (KRB) are 
contiguous in this arrangement because the software does not allow 
another I/O operation to begin while the controller is busy. A 
separate unit control block (UCB) describes each unit attached to the 
controller. The UCBs are associated with the SCB, which contains’ the 
context of the operation currently in progress. 


2.3.2 Single Controller, Serial Operation 


Another typical conventional arrangement of structures for a 
user-written driver is shown in Figure 2-2, which could represent two 
LPll controllers, one with an LPO04 and the other with an  LPOS5 
attached. It represents the simplest case of driver processing. 
Figure 2-2 shows what is required for a controller that allows only a 
Single I/0 operation for each controller. A single controller table 
defines the existence of the controller type on the_ system. One 
device control block establishes the characteristics for the type of 
device running on the controller. 


The status control and controller request blocks are contiguous in 
this arrangement because, while the controller is busy, another I/0 
operation cannot begin. Only one SCB is necessary to store the 
context of the unit operation. The UCB points to the SCB, which in 
turn points to the KRB of the unit's controller. Because the system 
must handle interrupts from multiple controllers, the controller table 
points to the KRB of each controller present. 
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Figure 2-1 Multiple Units per Controller, Serial Unit Operation 


2.3.3 Parallel Unit Operation 


Some devices, such as the RKO6, allow multiple units to have’ seek 
operations in progress at the same time. In particular, the RKO06 
allows such operations to overlap a data operation. Figure 2-3 shows 
the arrangement needed in the software structures to support parallel 
operations on one controller, 


Two additional structural changes are required from the _ serial 
operation arrangement. First, because more than one unit may have an 
operation pending at the same time, a structure is needed to. store 
unit context. Therefore, for each unit (and each unit control block) 
there is a separate status control block. Second, because interrupts 
can come from more than one unit, some way must exist to access the 
Proper unit. As a result, the controller request block contains a 
table of unit control block addresses that allows the driver to find 


the structures for the unit generating an interrupt. 
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Figure 2-2 Single Controller, Serial Operation 
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Figure 2-3 Parallel Unit Operation (Overlapped Seek) 


2.3.4 Multiple-Access (Dual-Access) Operation 


Some devices, such as the RKO6, have a dual port option that provides 
multiple-access paths to units. On the RKO6, dual ports on the unit 
enable a single unit to be electronically switched between two 
controllers. Figure 2-4 shows the several changes in the structures 
needed to support dual-access operations. 
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Figure 2-4 Dual-Access Operation 


Separate status control blocks are needed for each unit because, if 
one controller is currently busy, the alternate controller can be idle 
and allow the operation to proceed. The difference in the dual-access 
structure is that the SCB_ no longer points to the same controller 
request. block all the time as in the overlapped seek arrangement. The 
Executive can change the SCB pointer to a KRB to reflect the 
capability to electronically switch a unit between two controllers. 


To enable the software to differentiate which controllers may access a 
unit, the SCB has a table of KRB addresses. For dual-access disks, 
the table contains two entries: the addresses of the controller 
request. blocks for each controller between which the unit can be 
switched. 


2.4 OVERVIEW OF DATA STRUCTURE RELATIONSHIPS 


This section presents an overview of the relationships among the 
user-written driver data structures previously introduced in this 
chapter and the Executive I/O structures and DIGITAL-supplied driver 
structures. The goal of the section is to convey the general manner 
in which user-written structures and code link into the system I/0 
scheme and to describe generally the use to which the system puts the 
structures. The specific user-written structures are simplified 
somewhat so that the emphasis is placed on the linkages with other 
parts of the system rather than on the details of user-written 
structural relationships. 
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This section should be used with Section 2.3 to understand the general 
structural concepts. For example, Section 2.3 describes various 
arrangements of unit control, status control, and controller request 
blocks based on hardware functions the software structures support. 
This section treats such arrangements as an engineering black box that 
is oriented in the general I/O environment. Thus, in the generalized 
I/O data structure depicted in this section, the pointers in the KRB 
table of the SCB are not shown and the table is simply marked KRB 
Table. 


Figure 2-5, which provides the basis for the presentation of the I/0 
data structure, shows the individual elements and the important link 
fields within them. The numbers in the figure correspond to the 
numbers in the lead paragraphs of the text to simplify the discussion 
and to guide you through the data structures. 


1. The location represented by the Executive symbol S$DEVHD is a 
cell in system common (SYSCM). It is the head (or start) of 
a singly-linked, unidirectional list of all device control 
blocks in the system. The first word in each DCB is a link 
to the next DCB. 


The list of device control blocks is one of the two threads 
through the system data tables for device-related 
information. For example, the list is the means by which 
executive routines scan the data structures to determine what 
devices are on the system and what is the status of units. 
User-written device control blocks must be linked into the 
list of system defined DCBs. 


2. Every loadable driver is associated with a partition control 
block (PCB). The PCB defines the characteristics of the 
memory area into which the -.driver is loaded. The Executive 
and tasks such as LOA and UNL reference the data in the PCB. 
A driver is not concerned with the PCB. 


3. If a task is attached to a unit, the UCB has a pointer to the 
task control block (TCB) of that task. 


4. The task header is an independent entity in the I/0 data 
Structure and the driver never accesses it. A copy of the 
task header is taken from the task partition and stored in 
the Executive dynamic storage region whenever the task is 
actually in memory. This copy is then used by the Executive. 


A logical unit table (LUT) entry in the task header has_ two 
items of interest: a pointer to an associated unit control 
block and, if a file is being accessed, a pointer to a window 
block. The Executive accesses the logical unit table of a 
task during a QIO request and indexes the table by the 
logical unit number specified in the QIO request. 


5. A device control block has a pointer to the unit control 
block of the first related unit. Because the length of a UCB 
is stored in the DCB and all UCBs are allocated in a 
continuouS area, access to all the UCBs related to that DCB 
is possible. This arrangement allows software to access all 
related unit information for a device type. 


A DCB also has a pointer to the start of the driver dispatch 
table. This pointer allows the Executive to call the driver 
at its entry points to process an I/0O-related or a 
reconfiguration request. 
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Figure 2-5 Composite I/O Data Structures 
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Each unit control block contains a pointer back to its 
related DCB. This backpointer allows the Executive interrupt 
dispatch code to enter the proper driver (through the pointer 


to the driver dispatch table). 


Associated with each UCB is a status control block. The SCB 
is shared by all units for a device type that does not 
require units to operate in parallel. When units can operate 
in parallel, each UCB has its own associated SCB. 


As part of processing a QIO directive (queued I/O request), 
the Executive builds a structure called an I/O packet. 
Storage for packets is in the system dynamic storage region 
(the pool). The Executive connects the packets by a pointer 
in each packet to form a singly-linked list called the I/0 
queue. The Executive maintains two pointers in the SCB to 
the list of packets. The first pointer is to the start of 
the list and the second pointer is to the last packet in the 
list. 


The driver should not access the list of I/0 packets 
directly. When the Executive transfers control to the driver 
to initiate processing of an I/O request, the driver 
immediately calls an Executive service routine to get a 
packet to process. The routine passes, to the driver, data 
sufficient to process the request (for example, the address 
of the packet). Thus, the Executive, and not the driver, 
removes a packet from the queue of packets. However, in 
performing the I/O request, the driver can access certain 
fields in the packet to be processed because a pointer to the 
currently active I/O packet is kept in the SCB.1 


The Executive determines the ordering of packets in the 
queue. Typically, higher-priority requests are placed at the 
head of the queue. 


At least one status control block (SCB) exists for each 
controller. Where a controller and software support 
operations in parallel on multiple units, one SCB exists for 
each unit capable of operating independently. A pointer in 
the SCB connects to the controller request block (KRB) of the 
controller to which the related unit is connected. If 
multiple-access paths between a unit and controller are 
possible, the KRB pointer is dynamic. The KRB to which the 
SCB points at one instant therefore, is considered to be the 
currently assigned KRB. To reflect the existence of 
alternate controllers, a table of pointers to all the 
possible KRBs is contained in the SCB, Separate from the 
pointer to the currently assigned KRB. 


The fork block in the SCB contains some of the driver process 
context. The driver executes an Executive routine so that 
processing will occur at fork level. To preserve processing 
status, the routine stores some context in the fork block. 
When the driver eventually runs again, the fork processor 
recovers the proper context from the fork block. 


l. Normally, the driver does not directly manipulate the I/O queue. 
An exception is when a driver needs to examine an I/O packet before it 
is queued or instead of having it queued. This exception involves a 


status 


bit in a control byte of the unit control block. For more 


information on queuing of I/O packets to the driver, refer to the 
description of the UC.QUE bit in Section 4.4.4. 
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On multiprocessor systems, the fork block contains an extra 
cell to define the processor on which the driver must execute 
the I/O request. The Executive routine that preserves 
context in the fork block ensures that certain driver code is 
processed on a particular processor. 


The fork blocks for pending driver processes are connected in 
a sSingly-linked list, the head of which is in a location 
(SFRKHD) in the Executive’ region. Generally, the fork 
processing routines link a fork block in FIFO order. At 
location $FRKHD+2 the executive maintains a pointer to the 
last fork block in the list. 


Associated with each open file on a mounted volume is a_ file 
control block (FCB). The file system alone uses the FCB to 
control access to the file. 


For each open file on a mounted volume, a window block exists 
for each task that has the file open to hold pointers to 
areas on the volume on which the file resides. The function 
of the window block is to speed up the process of retrieving 
data items from the file. (The associated ACP need not be 
called to convert a virtual block number ina file to a 
logical block number on the device.) The driver is not 
concerned with the window block. 


The driver dispatch table (DDT) is part of tthe driver code 
and, through the vector and the interrupt control block, is 
the means by which the device interrupts are passed to the 
driver. 


The controller request blocks (KRB) are linked into the I/0 
data structure through the pointers in the controller table 
(CTB). The table of KRB address in the CTB is static. 


The KRB table allows the Executive access to the structures 
for a controller when it initiates an interrupt. To report 
the termination of a data transfer command, a controller 
initiates an interrupt. (While such a controller-initiated 
interrupt is in progress, the hardware delays interrupts from 
units.) The Executive determines the correct KRB by indexing 
the CTB with the controller number from the PS word in the 
vector. 


For a controller that allows unit operation in parallel 
(overlapped seek support), the related KRB must have a table 
of UCB addresses. This table allows the driver to access the 
structures of the unit that generates an interrupt. When a 
unit interrupts, its controller records (in the attention 
Summary register) the physical number of the interrupting 
unit. The driver must retrieve the number and use it to 
index the UCB table in the KRB to access the proper unit 
control block. 


To support unit operation in parallel, the KRB also’ contains 
a queue to regulate controller access. This queue, the 
controller request queue, is a list of fork blocks for driver 
processes that have requested and have been denied access to 
the controller. The driver requests access to a controller. 
If the controller is busy, the Executive forces the driver to 
wait for access by placing the fork block in the queue of 
Processes waiting for access. The Executive gives precedence 
to control access over requests for data transfer by placing 
positioning requests onto the front of the queue and adding 
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data transfer requests to the end of the queue. When a unit 
is given access, the controller status is set to busy and 
unit UCB address is set to connect the KRB to the owned UCB. 


To indicate what unit to process on a controller initiated 
interrupt, a cell in the KRB points to the unit control block 
(UCB) of the unit that currently owns the KRB. 


The KRB queue cells have two words. The first word points to 
the fork block in the SCB of the next unit to get access. 
The second word points to the fork block in the SCB of the 
last unit to get access. If the first word is 0, then the 
second word points to the first and no unit is waiting for 
access to the controller. 


The location represented by the Executive symbol S$CTLST is a 
cell in system common (SYSCM). It is the head (or start) of 
a singly-linked, unidirectional list of all controller tables 
(CTBS) in the system. A word in each CTB is a link to the 
next CTB. The last CTB in the list contains a link word of 
0. 


The list of controller tables is one of the two threads 
through the system for device-related information. (The list 
of device control blocks is the other thread.) A uSer-written 
controller table must be linked into the list of 
system-defined CTBs. This list is the mechanism by which 
system routines, such as those for reconfiguration, access 
I/O data structures for hardware information. 


One volume control block (VCB) exists for each mounted volume 
in the system. The VCB maintains volume-dependent control 
information. 


Pointers within the VCB connect to the file control block 
(FCB) and window block (WB). The FCB and WB control access 
to the volume's index file, which is a file of file headers. 
All FCBs for a volume form a linked list starting from the 
index file FCB. These linkages aid in keeping file access 
time to a minimum. A conventional driver does not access any 
of these structures. 


CHAPTER 3 


EXECUTIVE SERVICES AND DRIVER PROCESSING 


The Executive provides services related to I/O drivers. Some services 
are provided before a driver process is initiated and are therefore 
called predriver initiation services. The predriver initiation 
services are those performed by the Executive during its processing of 
a QIO directive; these services are not available as Executive calls. 


Predriver initiation processing extracts from the QIO directive all 
I/O support functions not directly related to the actual issuance of a 
function request to a device. If the outcome of predriver initiation 
processing does not result in the queuing of an I/O Packet to a 
driver, the driver is unaware that a QIO directive was issued. Many 
QIO directives do not result in the initiation of an I/O operation. 


Other services are available to the driver after it has been given 
control, either by the Executive or as the result of an interrupt. 
They are available as needed by means of Executive calls. 


An important concept used in this section and in Chapter 4 is the 
state of a process. In RSX-l11M-PLUS, a process can run in one of two 
states, user or system. Drivers operate entirely in the system state; 
the programming standards described in Chapter 4 apply to system~state 
processes. 


3.1 FLOW OF AN I/O REQUEST 


Following an I/O request through the system at the functional level 
(the level at which this chapter is directed) requires that limiting 
assumptions be made about the state of the system when a task issues a 
QIO directive. The following assumptions apply: 


e The system is running and ready to accept an I/O request. All 
required data structures for supporting devices attached to 
the system are intact. 


e The only I/O request in the system is the sample request under 
discussion. 


e The example progresses without encountering any errors’ that 
would prematurely terminate its data transfer; thus, no error 
paths are discussed. 


e The controller in question executes only a single operation at 
a time, 
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Predriver Initiation Processing 


The I/O flow proceeds as described below: 


Ls 


Task issues QIO directive 


The user program first either statically (by QIOWSC, QIOWS, 
QIOSC, or QIOS) or dynamically (by QIOWSS or QIOSS) creates a 
directive parameter block (DPB) containing information about 
what I/0 is to be performed on what device. Then, it issues 
the directive. 


All Executive directives are called by means of EMT 377. The 
EMT causes the processor to push the PS and PC on the stack 
and to pass control to the Executive's directive processor. 


QIO Dispatching 


The Executive directive dispatcher DRDSP ascertains that’ the 
EMT is a QIO directive and calls the QIO directive processor 
DRQIO. 


First-level validity checks 


The QIO directive processor validates the logical unit number 
(LUN) and the Unit Control Block (UCB) pointer. DRQIO checks 
whether the LUN supplied in the directive parameter block is 
a legal value. If it is not a legal value, the directive is 
rejected. If the LUN is legal, DRQIO checks whether a valid 
UCB pointer exists in the Logical Unit Table (LUT) for the 
specified LUN. This check ascertains whether the LUN is 
assigned. If the check fails, the directive is rejected. If 
both these checks are successful, DRQIO then performs’ the 
redirect algorithm, 


Redirect algorithm 


Because the UCB may have been dynamically redirected by a 
Redirect command, QIO directive processing traces’ the 
redirect linkage until the target UCB is found. The target 
UCB provides the links to most of the other structures of the 
device to which the I/O operation will be directed. 


Additional validity checks 


The event flag number (EFN) is validated, as well as_ the 
address of the I/O Status Block (IOSB). If either is 
illegal, the directive is rejected. Immediately following 
successful validation, DRQIO resets the event flag and clears 
the I/O status block. 


Obtain storage for and create an I/O Packet 


The QIO directive processor now acquires a 20-word block of 
dynamic storage for use as an I/O Packet. It inserts into 
the packet the device-independent data items that are used 
subsequently by both the Executive and the driver in 
fulfilling the I/O request. Most items originate in the 
requesting task's Directive Parameter Block (DPB). 


At this point, DRQIO sets the directive status to +1, which 
indicates directive acceptance. Note that a directive 
rejection is a return to the caller with the C bit set. In 
addition, a directive rejection is transparent to the driver. 
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Validate the function requested 


If the function is legal, DRQIO checks to see whether’ the 
unit is on-line. If the unit is off-line, the packet is 
rejected. The function is one of four possible types: 


Control 
No-op 
ACP 
Transfer 


With the exception of Attach/Detach, control functions are 
queued to the driver. If the bit UC.ATT is” set, 
Attach/Detach will also be queued to the driver. If the 
requested function does not require a call to the driver, the 
Executive takes the appropriate action and calls the I/0 
Finish routine (S$IOFIN). 


No-op functions do not result in data transfers. The 
Executive performs them without calling the driver. No-ops 
return a status of IS.SUC in the I/O status block. 


ACP functions may require processing by the file system. 
More typically, the request is ae read or write virtual 
function that is transformed into a read or write logical 
function without requiring file-system intervention. When 
transformed into a read or write logical function, the 
function becomes a transfer function (by definition). 


Transfer functions are address checked and queued to the 
proper driver. This means that DRQIO checks the address of 
the I/O buffer, the byte count, and the alignment requirement 
for the specified device. If any of these checks fails, 
DRQIO calls the I/O Finish routine (SIOFIN), which returns an 
I/O error status and clears the I/O request from the system. 
If the checks Succeed, DRQIO either places the I/O Packet in 
the driver request queue according to the priority of the 
requesting task or, if the UC.QUE bit is set, gives’ the 
packet directly to the driver. (See Section 4.4.4 for a 
description of the UC.QUE bit.) 


Driver Processing 


Request work 


To obtain work, the driver calls Get Packet (SGTPKT). SGTPKT 
either provides work, if it exists, or informs the driver 
that no work is available or that the SCB is busy; if fio 
work exists, the driver returns to its caller. If work is 
available, SGTPKT sets the device controller and unit to 
busy, dequeues an I/O request packet, and returns to the 
driver. 
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9. Issue I/O 


From the available data structures, the driver initiates the 
required I/O operation and returns to its caller. A 
subsequent interrupt may inform the driver that the initiated 
function is complete, assuming the device is interrupt 
driven. 


10. Interrupt processing 


When a previously issued I/O operation interrupts, the 
interrupt causes the driver to be entered. The driver 
processes the interrupt according to the programming protocol 
described in Chapter l. According to the protocol, the 
driver may process the interrupt at priority 7, at _ the 
priority of the interrupting device, or at fork level. If 
the processing of the I/O request associated with the 
interrupt is , still incomplete, the driver initiates further 
I/O on the device (Step 9). When the processing of an I/0 
request is complete, the driver calls SIODON. 


ll. I/0 Done processing 


SIODON removes the busy status from the device unit = and 
controller, queues an AST if required, and determines whether 
a checkpoint request pending for the issuing task can now be 
effected. The I0SB and event flag, if specified, are 
updated, and SIODON returns to the driver. The driver 
branches to its initiator entry point and looks for more work 
(Step 8). This procedure is followed until the driver finds 
the queue empty, whereupon the driver returns to its caller 
and the driver process vanishes. 


Eventually, the processor is granted to another ready-to-run 
task that issues a QIO directive, Starting the I/O flow anew. 


3.2 EXECUTIVE SERVICES AVAILABLE TO A DRIVER 

Once a driver is given control following an I/O interrupt or by the 
Executive itself, a number of Executive services are available to the 
driver. These services are discussed in detail in Chapter 7. 


However, four Executive services merit special emphasis because 
virtually every driver in the system uses them: 


l. Get Packet (SGTPKT) 
2. Interrupt Save (SINTSV) 
3. Create Fork Process (S$FORK) 


4. I/0 Done ($IODON or $IOALT) 
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3.2.1 Get Packet ($GTPKT) 


The Executive, after it queues an I/O Packet, calls the appropriate 
driver at its I/O initiation entry point. The driver then immediately 
calls the Executive routine S$GTPKT to obtain work.! If work is 
available, SGTPKT delivers to the driver the highest-priority, 
executable I/O Packet in the driver's I/O queue, and sets the SCB 
status to busy. If the driver's I/O queue is empty or if the driver 
is busy, SGTPKT returns a no=-work indication. 


If the SCB related to the device is already busy, S$GTPKT so informs 
the driver, and the driver immediately returns control to the 
Executive. 


Note that, from the driver's point of view, no distinction exists 
between no~work and SCB busy, because an I/O operation cannot be 
initiated in either case. 


3.2.2 Interrupt Save (SINTSV) 


A driver should not directly call the SINTSV coroutine but should use 
the INTSV$ macro call. Therefore, if the driver is loadable, it need 
not call SINTSV and the macro will not generate the call in the 
driver. (The interrupt save processing is done by either’ the 
interrupt control block or the appropriate common interrupt routine in 
the Executive.) If a driver is resident, the INTSVS macro call 
generates the call to the SINTSV coroutine. The coroutine saves code 
in the driver because the call is shorter than the code to save and 
restore the conventional registers R4 and R5. More importantly, the 
SINTSV coroutine gets the driver onto the system stack if it is not 
already there. The INTSV$ macro is described in more detail in 
Section 4.3 and the interrupt entry point is described in Section 4.5. 


3.2.3 Create Fork Process (S$FORK) 


Synchronization of access to shared data bases is accomplished by 
creating a fork process. When a driver needs to access a Shared data 
base, it must do so as a fork process; the driver becomes ae fork 
process by calling S$FORK. The SCB contains preallocated storage for a 
4- or 5-word fork block. See Section 4.4.5 for a description of the 
fork - block. Section 7.4 contains details on SFORK. After SFORK is 
called, a routine is fully interruptable (priority 0), and its access 
to shared system data bases is strictly linear. 


3.2.4 I/0 Done (SIODON or SIOALT) 


At the completion of an I/O request, the subroutines SIODON or SIOALT 
perform a number of centralized checks and additional functions: 


e Store status if an IOSB address was specified 


e Set an event flag if one was requested 


1.An exception is a driver that handles special user buffers. Such a 
driver must call certain other Executive routines before calling 
SGTPKT. See Section 4.4.4 for a description of the UC.QUE bit. 
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@e Determine whether a checkpoint request can now be honored 
@ Determine whether an AST should be queued 
SIODON and SIOALT also declare a significant event, reset the SCB_ and 


device unit status to idle, and release the dynamic storage used by 
the completed I/O operation. 


CHAPTER 4 


PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER 


Chapters 2 and 3 give overviews of data structures and Executive 
services, respectively. This chapter summarizes programming 
Standards, presents overviews of programming requirements for 
user-written driver code and data, and gives details of the data 
structures and driver code. Executive services are covered in Chapter 
ae 


4.1 PROGRAMMING STANDARDS 


I/O drivers function as integral components of the RSX-11M-PLUS 
Executive, and this manual enables you to incorporate I/O drivers into 
your syStem. User-written drivers must follow the same conventions 
and protocol as the Executive itself if they are to avoid complete 
disruption of system. service. Failure to observe the _ internal 
conventions and protocol that are described fully in Chapter 1 can 
result in poor service and reductions in system efficiency. 


The programming conventions used by RSX-11M-PLUS system components are 
identical to those described in Appendix E of the PDP-11 MACRO-11 
Language Reference Manual. DIGITAL urges you to adhere to these 
conventions. 


4.1.1 Programming Protocol Summary 


Drivers are required to adhere to the following internal conventions 
when processing device interrupts: 


l. No registers are available for use unless SINTSV has_ been 
called, or the driver explicitly performs save and restore 
operations. If S$INTSV is called, registers R4 and R5 are 
available; any other registers must be saved and restored. 
If the driver is to call SINTSV directly, it must do so 
immediately because SINTSV attempts to retrieve the 
controller number from the PS. 


2. Noninterruptable processing must not exceed 20 instructions, 
and processing at the priority of the interrupting source 
must not exceed 500us. 


3. Only a fork process should modify system data bases. 
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4.1.2 Accessing Driver Data Structures 


All the driver data structure elements have symbolic offsets. Because 
the prysSical offset values may vary from one version of the Executive 
to another, your user-written driver code should always use the 
Symbols to access the elements. 


Accordingly, your driver code should not step from one structural 
elemen=: to another (relying on the juxtaposition of data structures 
and inilividual words in a data structure) but should access’ each 
elemen: by symbolic offset. By following this aspect of good coding 
practize, you can reduce debugging time when converting an RSX-11M 
driver to run on RSX-11M-PLUS. Many of the offsets in the RSX-11M SCB 
differ physically from those in the RSX-11M-PLUS SCB but have the same 
symbolic values. 


On the other hand, it is a common coding practice to assume that zero 
offset; (particularly link pointers such as D.LNK) will remain Zero. 
This assumption allows the saving of one word per instruction by 
Substi:zuting an instruction such as MOV (R3),R3 for MOV D.LNK(R3),R3. 
DIGITA. recognizes that such practices are followed and consequently 
attemp':s to keep such offsets zero. 


4.2 OVERVIEW OF PROGRAMMING USER-WRITTEN DRIVER DATA BASES 


You should create the source code for your user-written driver data 
base on ae file separate from that of the driver code. You assemble 
this fle to create the driver data base module. If you make - your 
data base resident, your data base module will be linked separately 
from the driver code and will be linked to the system device tables 
module SYSTB.OBJ. (The source code for the SYSTB module is created in 
UFD [1.,10] during system generation.) If your data base is in a 
separate module and is to be loadable, it will be linked to the end of 
the dr’ ver code module. If your driver data base is in the same 
module as that of your driver code, it must be at the end of the 
driver code. 


The detailed descriptions of the driver data structures are in Section 
4.4, A few fields in the structures are conditional on certain 
features in the Executive. You therefore must use conditional 
assemb]y directives and some system-wide symbols that are defined in 
the Executive assembly prefix file RSXMC.MAC, which is created during 
system generation. 


To create the source code, you need to know, in addition to the 
detailed structures, what ordering and labeling are required. These 
requirements, though not extensive, are important in Jlinking = and 
loadinc your driver data base. The general coding requirements for 
both lcadable and resident driver data bases are described in the 
following subsections. 


4.2.1 General Labeling and Ordering of Data Structures 


If you are creating a loadable data base, you must specify, for the 
LOAD rcutines, two global labels as follows: 


SxxDAT:: marks the start of the user-written driver data base. 
SxxEND:: marks the end of the user-written driver data base, 


that is, immediately following the final word of the 
data base. 
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The characters xx represent the 2-character mnemonic of the device 
that your driver data base supports. If either or both of these 
labels are not defined, LOAD cannot determine the length of your data 
base when you attempt to load your driver. 


There is no mandatory ordering of the different structures in a driver 
data base. DIGITAL suggests, however, that you place the DCB first, 
followed by the UCB, the SCB(s), the KRB(s), and the CTB. If you do 
not follow this ordering scheme, you must specify the starting 
location of the first (or only) DCB as described in Section 4.2.2. 


4.2.2 Device Control Block Labeling 


If the data base for a driver is to be loadable, the LOAD routines 
require either that the first (or only) DCB be identified by the 
global label $xxDCB:: or that the DCB be at the start of the data 
base. 


If the data base for a driver is to be resident, you must define the 
Start of the first (or only) DCB with the global label S$USRTB::. This 
label is required to link the last DCB defined in tthe SYSTB module 
with the DCB in your driver data base. If you fail to supply this 
symbol, the Task Builder will generate an undefined reference error 
when it builds the Executive. 


4.2.3 Unit Control Block Ordering 


All the UCBs associated with a specific device control block (DCB) 
must be contiguous with each other and must be of equal length. These 
requirements are necessary because the DCB has only one link to the 
UCBs, and that link is to the first UCB. Two data elements, the UCB 
length and the number of units, are stored in the DCB; they, together 
with the link to the first UCB, are used to locate subsequent UCBs. 
If you do not follow these requirements, no software can access the 
UCBs. 


4.2.4 Status Control and Controller Request Blocks 


All user-written drivers that do not need separate storage for 
independent unit context should use the continuous allocation of the 
KRB and SCB. (For an explanation of when independent unit context is 
required, refer to the discussion of overlapped seek I/O in Section 
1.4.1.) Therefore, the KRB and SCB are contiguous and some fields of 
each structure overlap. This arrangement saves space that would be 
required for one SCB for each independent unit. Because only one unit 
can be active at any one time, all units attached to the same 
contrcller can share the SCB. This arrangement of the KRB and the SCB 
is described in Section 4.4.7. 


4.2.5 Controller Table 


You must define the start of the table of KRB addresses in the CTB 
with the global label $xxCTB::. Both the INTSV$ macro call and the 
Executive LOAD routines require this label. 


If your data base is resident, you must use the CTB macro at the CTB 


link word L.LNK. The CTB macro automatically generates a global label 
that provides the linkage between the last CTB defined in the SYSTB 
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module and the cCTB defined in your driver tables module. (The 
definition of the CTB macro is created in the file RSXMC.MAC during 
system generation.) 


4.3 OVERVIEW OF PROGRAMMING USER-WRITTEN DRIVER CODE 


To create the source code to drive a device, you must perform. the 
following steps: 


1. Thoroughly read and understand this manual. 


2. Familiarize yourself in detail with the physical device and 
its operational characteristics. 


3. Determine the level of support required for the device. 
4. Determine actions to be taken at the driver entry points. 
5. Create the driver source code. 


You can write driver code for RSX-lIM-PLUS that does one of the 
follow-.ng: 


1. Supports standard functions and runs on RSX-11M-PLUS only. 


2. Supports standard functions and is written so that it is 
compatible with use on both RSX-11M and RSX-11M-PLUS. (This 
driver needs separate data bases for each system.) 


3. Supports advanced features and runs on RSX-11M-PLUS only. 
(Although Chapter 1 discusses advanced features, this manual 
does not describe how to program advanced features. Your 
best guide to utilizing advanced features is to use a 
DIGITAL~supplied driver as a model.) 


To assist you in generating proper code for your user-written driver 
and to provide a stable user-level interface from one release of the 
system to another, RSX-l11M-PLUS provides the macro calls listed in 
Table 4-1. 


The definitions of the system macro calls for drivers are in the 
Executive assembly prefix file RSXMC.MAC. The following subsections 
describe the format of the macro calls and other features of 
user-written driver code. Driver code details (such as labeling 
requirements and entry point conditions) are presented in Section 4.5. 


4.3.1 Generate Driver Dispatch Table Macro Call - DDT$ 


The DDTS macro call facilitates generation of tthe driver dispatch 
table. The format of the DDT$ macro call is as follows: 


DDTS dev ,nctrlr,iny,inx,ucbsv,NEW, OPT, BUF 


Table 4-2 lists the arguments of the DDT$ macro call. The macro 
constructs the DDT, using as addresses those locations indicated by 
the standard labels. The macro has arguments allowing you to tailor 
some of the standard entry points. The format of the DDT generated by 
the DDT$ macro is described in Section 4.5.1. 
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Table 4-1 
System Macro Calls for Driver Code 


Macro Name General Functions 


Used conventionally at the start of the driver code 
(1) to allocate storage for and to generate a 
driver dispatch table containing the addresses of 
entry points in the order in which the Executive 
expects them; (2) to generate special global 
labels required by the Executive; (3) to tell the 
Executive LOAD routines: (a) which controllers the 
driver supports, (b) how many interrupt vectors 
each controller supports, and (c) the association 
between the interrupt vectors and the driver 
interrupt entry points; and (4) to generate 
default controller and unit status change entry 
point procedures (for on-line and off-line 
transitions) 


GTPKTS Used at the I/O initiator entry point to generate 
the call to the $GTPKT routine and to generate code 
to save the address of the currently active unit's 
UCB 


INTSVS$ Used at an interrupt entry point to conditionally 
generate a call to the SINTSV routine and to 
generate code to load the UCB address of the 
interrupting device into R5 


Table 4-2 
DDT$ Macro Call Arguments 


is the 2-character device mnemonic. 


is the number of controllers that the driver services 
(counting from 1). 


allows the definition of no interrupt entry point or 
multiple interrupt entry points. If you leave the 
argument null, the macro generates as the interrupt 
entry point address the location defined by the 
conventional label $xxINT. 


If you specify NONE, no interrupt entry point is 
generated for the controller. 


If you specify an argument list of the form 
<aaa,bbb,...>, the macro generates multiple cells 
containing addresses defined by unconventional labels 
of the form $xxaaa and $xxbbb. This latter mechanism 
allows you to define multiple interrupt entry points 
in the driver. For example, the argument list 
<INP,OUT> generates two interrupt address labels of 
the form $xxINP and $xxOUT, the typical names used by 
drivers with two interrupt entry points. 
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Table 4-2 (Cont.) 
DDT$ Macro Call Arguments 


in uses an alternate I/O initiation entry point address 
label instead of the conventional xxINI form. If you 
specify inx, the macro uses as the only I/0 initiation 
entry point address the location defined by the label 
xxinx. 


uc Sv is for compatibility with RSX-11M drivers. If you are 
writing a driver for RSX-11M-PLUS, you should leave 
this argument blank. As a result, the macro does not 
allocate the space for the table of UCB addresses. 
For guidelines on specifying this argument, refer to 
Section 4.3.4. 


NEW distinguishes between RSX-11M-PLUS and RSX-11M 
drivers. If you specify this argument (any character 
except null), the macro generates two cells to hold 
the controller and unit status’ change entry point 
addresses. The referenced driver entry points must be 
labelled xxKRB: and xxUCB:. If your driver uses 
these entry points, it cannot be compatible with 
RSX-11M unless the two routines are conditionalized. 


If the argument is null, the macro generates code _ to 
use the xxPWF entry point for controller and unit 
on-line and off-line status changes. 


OP" indicates that the driver supports seek optimization. 
The referenced entry point must be labelled xxCHK:. 
The routine corresponding to that label should qualify 
the I/O request and convert it to cylinder track and 
sector. 


BUF required if the driver performs buffered input = and 
output. The entry point xxDEA: is generated. 


NOTE 


RSX-11M drivers implicitly handle controller 
and unit on-line and off-line status changes 
aS power failures. Although this default 
operation (enabled by code generated from 
leaving this argument null) is not optimal for 
operation on RSX-11M-PLUS, the driver will 
probably function properly without being 
changed to include the xxKRB and xxUCB entry 
points. 


4.3.2 Get Packet Macro Call -— GTPKTS 


The GTEFKTS macro call standardizes use of the Executive S$GTPKT 
routine, which retrieves an I/O packet for the driver to process. The 
format of the GTPKTS macro call is as follows: 


GTPKTS$ dev, nctrlr,addr,ucbsv,suc 


The description of the arguments appears in Table 4-3. 
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Table 4-3 
GTPKTS Macro Call Arguments 


dev is the 2-character device mnemonic. 


netrlir is the number of controllers that the driver’ services 
(counting from 1). 


addr is the local label defining the location at which to. 
continue execution if there is no I/O packet 
available. A driver typically executes a RETURN 
instruction when the SGTPKT routine indicates that 
there is no I/O packet to process. If you leave this 
argument null, therefore, the macro generates a RETURN 
instruction. 


ucbsv is for compatibility with RSX-11M drivers. If you are 
writing a driver for RSX-11M-PLUS, you should leave 
this argument null. The macro then generates code to 
load the pointer S.OWN with the address of the UCB 
returned by SGTPKT. For guidelines on using the 
argument, refer to Section 4.3.4. 


indicates single unit controller. If you are writing 
a driver for RSX-11M-PLUS that supports a controller 
type such as the LP1l, to which only a single unit can 
be attached, you should specify this argument (any 
character(s) except null). If you specify this 
argument, you should ensure that the offset 
K.OWN/S.OWN in the KRB(s) of your driver data base 
points to the UCB(s) of the unit(s) to which the 
controller(s) is attached. Thus, the macro does not 
generate code that stores the UCB address in the KRB 
(a gratuitous operation) for a device that has only 
one UCB per KRB. 


If your RSX-11M-PLUS driver has multiple units 
attached to the same controller, you should leave this 
argument null. The macro therefore generates code _ to 
Store in the KRB the UCB address of the unit to 
process. 


This macro call generates the call to the Executive SGTPKT routine. 
You should place it at the I/O initiation (xxINI) entry point because 
the SGTPKT routine is the standard manner for a driver to receive work 
from the Executive. When the driver receives control at its xxINI 
entry point, the Executive has loaded R5 with the address of the UCB 
of the unit that the driver must service. Because of the code the 
macro call generates, the driver immediately calls $GTPKT, which can 
set the C bit to indicate that no work is pending. The call 
additionally generates the BCS instruction that returns control to the 
calling routine when there is no work. If you specify an address as 
an argument in the macro call, it is used as the destination of the 
BCS instruction. The address is typically that of a RETURN 
instruction, but does not have to be. Eventually the driver must 
execute a RETURN to the system. 


The SGTPKT routine indicates that the driver has an I/O packet to 
process by clearing the C bit. Therefore, when the test of the BCS 
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instruction is false, execution continues inline and the driver can 
process the I/O packet that the Executive queued to it. The S$GTPKT 
routine leaves information in the driver registers to enable the 
driver to process the request. Refer to the description of the S$GTPKT 
routine in Chapter 7. 


4.3.3 Interrupt Save Macro Call - INTSVS$ 


You should specify the INTSVS$ macro call at each interrupt entry point 
in the driver. The macro conditionally generates a call to the 
Executive SINTSV routine based on whether the driver is loadable. The 
format of the INTSVS$ macro call is as follows: 


INTSVS dev,pri,nctrlr,pswsSv,ucbsv 


The arjuments of the call are described in Table 4-4. If the symbol 
LDSxx (where xx is the device mnemonic) is not defined, the macro 
generates the call to SINTSV and defines the priority at which the 
interrupt service routine will run. Not defining LD$xx indicates that 
the driver is resident. (For loadable drivers, the interrupt service 
routine in the Executive dispatches the interrupt.) For both loadable 
and resident drivers, however, the macro generates the code to load R5 


upon an interrupt. 


Table 4-4 
INTSVS Macro Call Arguments 


is the 2-character device mnemonic. 


is the processor priority (PR4, PR5 or PR6) at which 
the device runs and at which the SINTSV coroutine will 
run. 


ncetrlr is the number of controllers that the driver services 
(counting from 1). 


PSwsv is for compatibility with RSX-11M drivers. If you are 


writing an RSX-11M-PLUS driver, leave this argument 
null. If your driver is an RSX-11M driver, this 
argument has no effect. 


uchbsv is for compatibility with RSX-11M drivers. If you are 
writing a driver for RSX-11M-PLUS, you should leave 
this argument null. The macro generates code which 
uses the controller index returned in R4 by SINTSV, 
calculates the KRB of the interrupting controller, and 
loads the UCB address of the interrupting unit into 
RS. For guidelines on specifying this argument, refer 
to Section 4.3.4. 


4.3.4 Usage of UCBSV Argument in Macro Calls 


The DD’S, GTPKTS$, and INTSVS$ macro calls allow you to specify an 
argument (ucbsv) that maintains compatibility with RSX-11M drivers. 
RSX-lLIM-PLUS does not need to utilize the ucbsv’ argument. The 
argument ucbsv in the DDT$ macro allocates nctrlr words of storage 
(one word for each controller that the driver supports) and labels the 
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first word ucbsv:. This storage is the CNTBL area used by RSX-11M 
drivers to contain the address of the unit control block of the 
interrupting devices for each controller. Both the GTPKTS and INTSVS$ 
macro calls may use this same area. For more information concerning 
CNTBL, consult the RSX-11M Guide to Writing an I/O Driver. 


If you specify the argument ucbsv in the GTPKTS$ macro call, it must be 
the same label that you supplied for the ucbsv argument in the DDTS$ 
and INTSVS macro calls. The macro generates code to move the _ UCB 
address returned by SGTPKT to the correct location in the table 
starting at the label ucbsv. 


If you specify the argument ucbsv in the INTSVS$ macro call, it should 
be the same label you supplied for the ucbsv argument in the DDTS and 
GTPKT$ macro calls. The macro uses ucbsv to locate the UCB address of 
the interrupting unit, and then generates code to load the address 
into RS. 


4.3.5 Specifying a Loadable Driver 


To specify that a driver is loadable and to enable generation of 
conditional code, you must define the symbol LDSxx. The definition 
can appear in either the driver source code or the assembly prefix 
file RSXMC.MAC. It is usually more convenient to define the symbol in 
the driver source code because you probably will not have cause _ to 
edit RSXMC.MAC. When the symbol is defined, the INTSVS macro does not 
generate the call to SINTSV. 


4.3.6 Loadable Driver Entry Points for LOAD and UNLOAD 


A loadable driver that requires additional initialization and 
completion functions can define two entry points by labels of the form 
SxxLOA and $xxUNL (where xx is the 2-character device mnemonic). 
Because these two labels do not appear in the DDT itself, their format 
is fixed; you must use the exact format in your driver code. When 
you load the driver, the LOAD routines check for the $xxLOA entry 
point. 


NOTE 


The LOAD routines can perform this 
function only from MCR. If you attempt 
to load a driver that has the $xxLOA 
entry point from VMR, the load operation 
is terminated with the error message 
DRIVER REQUIRES RUNNING SYSTEM FOR 
LOAD/UNLOAD., 


The driver is entered, once per UCB, at the $xxLOA entry point at 
priority zero. At this stage, the driver data base has been loaded 
and pointers have been relocated. The driver is mapped through APR 5, 
and the following registers are set up: 


R3 - Controller index (undefined if S.KRB = 0) 
R4 -—- Address of the status control block 
R5 - Address of the unit control block 


The driver may use all the registers. When you unload the driver, the 
UNLOAD routine calls it at the $xxUNL entry point with the same 
conditions. 
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These two entry points in the loadable driver are independent of the 
contro..ler and unit status change entry points used by Executive 
reconfiguration software. That is, the two entry points $xxLOA and 
SxxUNL are used for initialization and completion at LOAD and UNLOAD 
time and not at on-line and off-line status change time. 


4.4 DRIVER DATA STRUCTURE DETAILS 


The following elements in the I/O data structure are of concern to the 
programmer writing a driver: 


l. The I/O packet 
2. The DCB 
3. The UCB 
4. The SCB 
5. The KRB 
6. The CTB 


The I/O data structure, and the control blocks listed previously in 
particular, contain an abundance of data pertaining to input/output 
operations. Drivers themselves are involved with only a subset of the 
data. 


NOTE 


Except where explicitly noted otherwise, 
all unused bits, fields, and words in 
all driver data base structures are 
reserved for DIGITAL system use _ and 
expansion, 


In the following descriptions, most data fields (words or bytes) are 
Classified by one of five descriptions. Two items in each description 
indicate: 


@e Whether the field is initialized in the data-structure source, 
and 


e What sort of access the driver has to the field during 
execution 


The five descriptions are: 


<initialized, not referenced> 
This field is supplied in the data-structure source code, and 


is not referenced by the driver during execution. 


<initialized, read-only> 
This field is supplied in the data-structure source code, and 
may be read by the driver. 


<not initialized, read-only> 
Either an agent other than the driver establishes this field, 
or the driver sets it up once and thereafter references it 


read-only. 
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<not initialized, read-write> 
Either the driver or some other agent establishes this field, 
and the driver may read it or write over it. 


<not initialized, not referenced> 
This field does not involve the driver in any way. 


These five descriptions cover most of the fields in the control blocks 
described in this section. No system software or hardware checks or 
enforces any of the access described. Exceptions are noted in the 
text. 


4.4.1 The I/O Packet 
Figure 4-1 shows the layout of the I/O Packet, which is constructed 
and placed in the driver I/O queue by QIO directive processing, and is 


subsequently delivered to the driver by a call to SGTPKT. The DPB 
from which the I/O Packet is generated is illustrated in Section 


4.4.2. 
Link to next 1/O packet 
a 


LUNK 


I.PRI } 
1.EFN 


|.TCB 


[reesarcone id 
erent 


LLN2 
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|.FCN 


1.10SB 


LAST 


1.PRM 


Device 
parameters 


Attachment Descriptor Pointer 
Attachment Descriptor Pointer 


ZK-254-81 


|L.AADA 


|. AADA+2 


Figure 4-1: 1/0 Packet Format 
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QIO directive processing dynamically builds the I/O packet from _ the 
data in the DPB. Fields in the I/O Packet (See the following text) 
are classified as: 

e Not referenced, 

@ Read-only, or 

e Read-write. 
I. LNK 

Driver access: 

Not referenced. 


Description: 


Links I/O Packets queued for a driver. A zero ends” the 
chain. The listhead is in the SCB (S.LHD). 


I. EFN 
Dviver access: 
Not referenced. 
Description: 


Contains the event flag number as copied by QIO directive 
processing from the requester's DPB. 


I. PRI 
Driver access: 
Not referenced. 
Description: 
Priority copied from the TCB of the requesting task. 
fires Oe 
Driver access: 


Not referenced usually. Sometimes referenced at I/O cancel 
and power failure. 


Description: 

TCB address of the requesting task. 
I.LN2 

Driver access: 
Not referenced. 

Description: 
Contains the address of the second word of the LUT entry in 
the task header to which the I/O request is directed. For 


open files on file-structured devices, this word contains the 
address of the Window Block; otherwise, it is zero. 


I.UCB 
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Driver access: 


Not referenced by conventional driver; frequently referenced 
by full duplex drivers. 


Description: 


I. FCN 


Contains the address of the unit to which I/0 is _ to be 
directed. I.UCB is the address of the Redirect UCB if the 
starting UCB has been subject to an MCR Redirect command. 
The field is referenced by the $GTPKT routine. 


Driver access: 


Read-only. 


Description: 


I. I0SB 


Contains the function code for the I/O request. It consists 
of two bytes. The high-order byte contains the function 
code; the low-order byte contains modifier bits. During 
predriver initiation the Executive compares the function code 
with a function mask value in the DCB. The driver interprets 
the modifier bits. 


Driver access: 


Not referenced. 


Description: 


I.IOSB contains the virtual address of the I/O Status Block 
(IOSB), if one is specified, or zero if one is not specified. 


I. IOSB+2 and I.IOSB+4 contain the address doubleword for the 
IOSB (see Section 7.2 for a detailed description of the 
address doubleword). The first word contains the relocation 
bias of the IOSB; the bias is, in effect, the number of the 
32-word block in which the IOSB starts. 


The second word is formatted as follows: 


Bits 0 through 5 Displacement in block (DIB) 
Bits 6 through 12 All zeros 
Bits 13 through 15 6 


The displacement in block is the offset from the block base. 
The value 6 in bits 13 through 15 is constant. It is used to 
cause an address’ reference through Kernel Address’ Page 
Register 6 (APR6). 


Discussion of the address doubleword is deferred to Section 
7.3 because you seldom have to be concerned with its contents 
or format in writing a conventional driver. Its construction 
and subsequent manipulation are normally external to the 
driver. Subroutines are provided as Executive services for 
programmed I/0 to render the manipulations of I/0 transfers 
transparent to the driver itself. 
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L.AST 
Driver access: 
Not referenced. 
Description: 


Contains the virtual address of the AST service routine to be 
executed at I/O completion. If no address is specified, the 
field contains zero. 


I. PRM 
Driver access: 
Read-write. 
Description: 


Device-dependent parameters constructed from the last six 
words of the DPB. Note that if the I/O function is a 
transfer (refer to the description of D.MSK in Section 
4.4.3), the buffer address (first DPB device-dependent 
Parameter) is translated to an equivalent address doubleword. 
Therefore, the virtual buffer address, which occupied one 
word in the DPB, occupies two words in I.PRM. AS a result, 
all other parameters in I.PRM are shifted by one word so that 
device-dependent parameter n is copied to I.PRM +(2*n)+2. 


Most DIGITAL-supplied drivers treat these words as a 
read/write storage area after their initial contents have 
been used. 


When the last word of the device-dependent parameters is 
nonzero, the value can have one of several special meanings 
to the Executive. For example, if the value is nonzero. and 
could be an Executive address, the Executive assumes that the 
value is a block locking word. Therefore, if the driver uses 
the word, it should restore its contents before calling 
SIODON. 


I.AADA 
I. AADA+2 


Driver access: 


Not referenced; maintained by the Executive transparently to 
the driver. 


Description: 


Two pointers, each to an attachment descriptor block of the 
region in which the task I/O buffer resides. These pointers 
account for I/O by region and enable the Executive to lock a 
region to make it noncheckpointable while I/O is in progress, 
and to unlock a region after I/O completes. 


4.4.2 The QIO Directive Parameter Block (DPB) 


The QIO DPB is constructed as shown in Figure 4-2. Usually drivers 
never access the DPB; the information is supplied here for general 
reference. 
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The parameters in the DPB have the following meanings: 
Length (required): 


The length of the DPB, which for the RSX-11M and RSX-11M-PLUS QIO 
directive is always fixed at 12 words. 


DIC (required): 


Directive Identification Code. For the QIO directive, this value 
is 1. For QIOW it is 3. 


Q.IOFN (required): 


The code of the requested I/O function (0 through 31). 


ee 
a.lopR/a.10EF 
Q.IOPL +0 14 


+2 


Device- 
dependent 
Parameters 


+4 


+6 


+10 


+12 


ZK-255-81 


Figure 4-2: QIO Directive Parameter Block (DPB) 


Modifier: 

Device-dependent modifier bits. 
Reserved: 

Reserved byte; must not be used. 
Q.IOLU (required): 

Logical Unit Number. 
Q.IOPR: 


Request priority. Ignored by RSX-11M-PLUS, but space must be 
allocated for IAS compatibility. 
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Q.IOEF (optional): 


Event flag number. Zero indicates no event flag. 


Q.IOSB (optional): 


This word contains a pointer to the I/O status block, which is a 
2-word, device-dependent I/O-completion data packet formatted as: 


Byte 0 
I/O status byte. 
Byte 1 
Augmented data supplied by the driver. 
Bytes 2 and 3 
The contents of these bytes depend on the value of byte 0. 
Lt byte 0O0= 1, then these bytes usually contain the 


processed byte count. If byte 0 does not equal 0, then the 
contents are device-dependent. 


Q.IOAE (optional): 


Address of the I/O done AST service routine. 


Q.IOPL 


The f 
with 


4.4.3 
Figur 
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D.LNK 


1. Pa 
value 


Up to six parameters specific to the device and to the I/0 
function to be performed. Typically, for data transfer 
functions, the following four are used: 

e Buffer address 

e Byte count 

e Carriage control type 


@ Logical block number 


ields for any optional parameters not specified must be filled 
Zeros. 


The Device Control Block (DCB) 
e 4-3 is a schematic layout of the DCB. The DCB describes’ the 
c characteristics of a device controller and the units attached 
e controller. All fields must be specified. 
ields! in the DCB are described as follows: 

‘link to next DCB) 


Driver access: 


Initialized, not referenced. 


renthesized contents following the symbolic offset indicate the 
to be initialized in the data base source code. 
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Description: 
Address link to the next DCB. If this cell is in the last 
(or only) DCB, you should set its value to zero. If you are 
incorporating more than one usSer-written driver at one time, 


then this field should point to another DCB in a DCB chain, 
which is terminated by a value of zero. 


D.UCB (pointer to first UCB) 
Driver access: 


Initialized, not referenced. 


; 
. 
: 
° 
: 
D.PCB 34 


Address of partition control block 


ZK-256-81 


Figure 4-3: Device Control Block 


Description: 
Address link to the U.DCB field of the first, and _ possibly 
the only, unit control block associated with the DCB. For a 
given DCB, all UCBs are in contiguous memory locations. and 
must all have the same length. 

D.NAM (ASCII device name) 

Driver access: 

Initialized, not referenced. 


Description: 


Generic device name in ASCII by which device units are 
mnemonically referenced. 
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D.UNIT (unit number range) 
Driver access: 
Initialized, not referenced. 
Description: 


Unit number range for the device. The low-order byte 
contains the lowest . unit number; the high-order byte 
contains the highest unit number. This range covers’ those 
logical units available to the user for device assignment. 
Typically, the lowest number is zero, and the highest is n-l, 
where n is the number of device-units described by the DCB. 


D.UCBL (UCB length) 
Driver access: 
Initialized, not referenced. 
Description: 


The unit control block can have any length to meet the needs 
of the driver for variable storage. However, all UCBs for a 
given DCB must have the same length. The specified length 
must include prefix words (such as U.LUIC and U.OWN), if 
present. 


D.DSP (driver dispatch table pointer) 
Driver access: _ 
Initialized, not referenced. 
Description: 


Address of the driver dispatch table, which is located within 
the driver code. (When the Executive wishes to enter the 
driver at any of the entry points contained in the driver 
dispatch table, it accesses D.DSP, locates the appropriate 
address in the table, and calls the driver at that address.) 
For a resident driver, your code references’ the symbol 
$xxTBL, which is generated by the DDT$ macro to mark the 
Start of the driver dispatch table. For a loadable driver, 
then, you should initialize this field to zero, which 
indicates that the driver is not in memory. 


D.MSK (driver-specific function masks) 
Driver access: 
Initialized, not referenced. 
Description: 
Eight words, beginning at D.MSK, are critical to the proper 
functioning of a device driver. The Executive uses these 


words to validate and dispatch the I/O request specified by a 
QIO directive. The following description applies only to 


PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER 


nonfile-structured devices.! Four masks, with two words per 
mask, are described by the bit configurations that you 
establish for these words: 


1. Legal function mask 
2. Control function mask 
3. No-op function mask 
4. ACP function mask 


The QIO directive allows for 32 possible I/O functions. The 
masks, aS stated, are filters to determine validity and I/0 
requirements for the subject driver. 


The Executive filters the function code in tthe I/O request 
through the four masks. The I/O function code is the 
high-order byte of the function parameter issued with the QIO 
directive. The decimal representation of that high-order 
byte is equivalent to the decimal bit number of the mask. If 
you want the function to be true in one of the four masks, 
you must set the bit in that mask in the position that 
numerically corresponds to the function code. For example, 
the code for I0.RVB is 21 £4(octal) and its decimal 
representation is 17. If you want IO.RVB to be true for a 
mask, therefore, you must set bit number 17 in the mask. 


The masks are laid out in memory in two 4-word groups. Each 
4-word group covers 16 function codes. The first 4 words 
cover the function codes 0 through 15; the second 4 words 
cover codes 16 through 31. Below is the exact layout used 
for the driver example in Chapter 8. 


-WORD 177477 ; LEGAL FUNCTION MASK CODES 0-15. 
-WORD 70 ;CONTROL FUNCTION MASK CODES 0-15. 
-WORD 0 ;NO-OP FUNCTION MASK CODES 0-15. 
-WORD 177200 ;ACP FUNCTION MASK CODES 0-15. 

-WORD 377 ;LEGAL FUNCTION MASK CODES 16.-31. 
-WORD 0 ;CONTROL FUNCTION MASK CODES 16.-31. 
-WORD 0 ;NO-OP FUNCTION MASK CODES 16.-31. 
~WORD 377 ;ACP FUNCTION MASK CODES 16.-31. 


The Executive filters the function code through the mask 
words sequentially as follows: 


Legal Function Mask: 


Legal function values have the corresponding bit position in 
this word set to 1. Function codes that are not legal are 
rejected by QIO directive processing, which returns IE.IFC in 
the I/O status block, provided an IOSB address was specified. 


1. Although no DIGITAL publication describes writing drivers’ for 
file-structured devices (drivers that interface with FI1ACP), you 
could write a disk driver by using a DIGITAL-supplied driver as a 
template. For example, the RK11 driver (DKDRV) is one that does not 
use advanced features. 
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Control Function Mask: 


If any device-dependent data exists in the DPB, and this data 
does not require further checking by the QIO directive 
Processor, the function is considered to be a_ control 
function. Such a function allows QIO directive processing to 
copy the DPB device-dependent data directly into the I/O 
Packet. 


No-op Function Mask: 


A no-op function is any function that is considered 
successful aS soon as it is issued. If the function is a 
no-op, QIO directive processing immediately marks the request 
successful; no additional filtering occurs. 


ACP Function Mask: 


If a function code is legal but specifies neither a control 
function nor a no-op, then it specifies either an ACP 
function or a transfer function. If a function code requires 
intervention of an Ancillary Control Processor (ACP), the 
corresponding bit in the ACP function mask must be set. ACP 
function codes must have a value greater than 7. 


In the specific case of read-write virtual functions, the 
corresponding mask bits may be set at your option. If the 
corresponding mask bits for a read-write virtual function are 
set, QIO directive processing recognizes that a file-oriented 
function is being requested to a nonfile-structured device 
and converts the request to a read-write logical function. 


This conversion is particularly useful. Consider a 
read-write virtual function to a specific device: 


1. If the device is file-structured and a file is open 
on the specified LUN, the block number specified is 
converted from a virtual block number in the file to 
a logical block number on the medium. Moreover, the 
request is queued to the driver as a_ read-write 
logical function. 


2. If the device is file-structured and no file is. open 
on the specified LUN, then an error is returned and 
no further action is taken. 


3. If the device is not file-structured, then the 
request is simply transformed to a read-write logical 
function and is queued to the driver. (The specified 
block number is unchanged.) 


Transfer Function Processing: 


Finally, if the function is not an ACP function, then it is 
by default a transfer function. All transfer functions cause 
the QIO directive processor to check the specified buffer for 
legality (that is, inclusion within the address space of the 
requesting task) and proper alignment (word or byte). In 
addition, the processor checks the number of bytes being 
transferred for proper modulus (that is, nonzero and a proper 
multiple). By convention, the first usSer-supplied parameter 
is the buffer address and the second is the byte count. 


D.PCB (0) 
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Creating Mask Words: 


Creating function mask words involves the following five 


steps: 


l. 


2. 


Establish the I/O functions available on the device 
for which driver support is to be provided. 


Build the Legal Function mask: Check the standard 
RSX-11M-PLUS function mask values in Table 4-6 for 
equivalencies. Only the IO.KIL function is 
mandatory. IO.ATT and I0.DET functions, if used, 
must have the RSX-11M-PLUS system interpretation. 
DIGITAL suggests that functions having an 
RSX-11M-PLUS system counterpart use the RSX-11M-PLUS 
code, but this is required only when the device is to 
be used in conjunction with an ACP. From the 
supported function list in Table 4-5, you can build 
the two Legal Function mask words. 


Build the Control Function mask by asking: 


Does this function carry a standard buffer address 
and byte count in the first two device-dependent 
parameter words? 


If it does not, then either it qualifies as a control 
function or the driver itself must effect the 
checking and conversion of any addresses to the 
format required by the driver. See Section 8.3 for 
an example of a driver that does this. (Buffer 
addresses in Standard format are automatically 
converted to Address Doubleword format.) 


Control functions are essentially those functions 
whose DPBs do not contain buffer addresses or counts. 


Create the No-op Function mask by deciding which 
legal functions are to be no-op. Typically, for 
compatibility with File Control Services (FCS) or 
Record Management Services (RMS) on 
nonfile-structured devices, the file access/deaccess 
functions are selected as legal functions, even 
though no specific action is required to access or 
deaccess a nonfile-structured device; thus, the 
access/deaccess functions are no-op. 


Finally, include the ACP functions Write Virtual 
Block and Read Virtual Block for those drivers that 
Support both read and write. (Include only one 
related ACP function if the driver supports only read 
or write). Other ACP functions that might be 
included fall into the nonconventional driver 
classification and are beyond the scope of this 
document. 


Driver access: 


Initialized, not referenced. 
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Description: 


Address of the driver's Partition Control Block (PCB). The 
driver data base source code must initialize the address to 
zero. The DCB can be extended by adding words after D.PCB. 


A PCB exists for every partition in a system. A driver PCB 
describes the partition in which it resides. 


The Executive uses D.PCB together with D.DSP (the address of 
the driver dispatch table) to determine whether a driver is 
loadable or resident and, if loadable, whether it is in 
memory. Zero and nonzero values for these two pointers have 
the meanings shown in Figure 4-4, 


D.PCB: 


Loadable 
driver, 


Resident 


= 0 ; : 
not in driver 
memory 
(not Poadable 
40 possible} driver, 


in memory 
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Figure 4-4: D.PCB and D.DSP Bit Meanings 


4.4.3.1 Establishing I/O Function Masks - Table 4-5 is supplied _ to 
assist you in determining the proper values to set in the function 
masks. The mask values are given for each I/0 function used by 
DIGITAL-supplied drivers. The bit number allows you to determine 
which mask group to use: for bits numbered 0 through 15, use the mask 
value for a word in the first 4-word group; for bits numbered 16 
through 31, use the mask value for a word in the second 4-word group. 


Of the function mask values listed in Table 4-5, only I0O.KIL is 
mandatory and has a fixed interpretation. However, if IO.ATT and 
IO.DET are used, they must have the standard meaning. (Refer to the 
RSX-11M/M-PLUS I/O Drivers Reference Manual for a description of 
Standarji I/O functions.) If QIO directive processing encounters a 
functio1 code of 3 or 4 and the code is not no-op, QIO assumes that 
these codes represent Attach Device and Detach Device, respectively. 
The otier codes are suggested but not mandatory. You are free to 
establish all other function-code values on nonfile-structured 
devices. However, the mask words must still reflect the proper 
fFilteriig process. 


If you are writing a driver for a file-structured device, you must 
establish the standard function mask values of Table 4-5. 


To dete-mine the proper bit masks for disks, tapes, and unit record 
devices (such as terminals, card readers, line printers, paper tape 
punches/readers), use Tables 4-6, 4-7 and 4-8 as guides. 
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Table 4-5 
Mask Values for Standard I/O Functions 


Related I/O 
Symbolic Function 


Cancel I/0 
Write Logical Block 
Read Logical Block 
10 Attach Device 
20 Detach Device 
40 General Device Control 
100 General Device Control 
200 General Device Control 
400 Diagnostics 
1000 Find File in Directory 
2000 Unlock Block 
4000 Remove File from Directory 
10000 Enter File in Directory 
20000 Access File for Read 
40000 Access File for Read/Write 
100000 Access File for Read/Write/Extend 
Deaccess File 
Read Virtual Block 
Write Virtual Block 
Extend File 
Create File 
Mark File for Delete 
Read File Attributes 
Write File Attributes 
ACP Control 
Unused 
Unused 
Unused 
Unused 
Unused 
Unused 
100000 Unused 
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Table 4-6 
Mask Word Bit Settings for Disk Drives 


RSX-11M-PLUS Related Symbolic 


0 Cc IO.KIL 
1 t IO.WLB 
2 t TO.RLB 
3 c IO.ATT 
4 c IO.DET 
5 Cc IO.STC 
6 

7 sa ITO.CLN 
8 sd Diagnostic 
9 a IO. FNA 
10 a IO.ULK 
11 a IO.RNA 
12 a IO. ENA 
3 a IO0.ACR 
14 a IO. ACW 
15 a IO. ACE 
16 a IO0.DAC 
17 a IO. RVB 
18 a IO0.WVB 
19 a IO. EXT 
20 a IO0.CRE 
21 a IO. DEL 
Ze a IO0.RAT 
23 a IO.WAT 
24 a IO. APC 


- transfer function, bit set only in legal function mask 

- control function, bit set in legal and control function masks 
- no-op function, bit set in legal and no-op function masks 

ACP function, bit set in legal and ACP function masks 

- special case, bit set only in ACP function mask, but not legal 
- special case, bit set only if diagnostic support in system and 
driver 


Nn 
aoewed act 
| 


Nn 
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Table 4-7 
Mask Word Bit Settings for Magnetic Tape Drives 


RSX-11M-PLUS Related Symbolic 


0 c IO.KIL 
1 t IO.WLB 
2 t IO.RLB 
3 Cc IO.ATT 
4 ral 1O.DET 
5 Cc I0.STC 
6 C 
7 IO.CLN 
8 Diagnostic 
9 IO. FNA 
10 IO. ULK 
11 IO.RNA 
12 IO. ENA 
13 I0.ACR 
14 I0. ACW 
15 IO.ACE 
16 IO.DAC 
17 IO. RVB 
18 IO.WVB 
19 10. EXT 
20 IO.CRE 
21 IO. DEL 
22 IO.RAT 
23 IO.WAT 
24 IO.APC 
25 
26 
27 
28 
29 
30 
31 


- transfer function, bit set only in legal function mask 

- control function, bit set in legal and control function masks 
- no-op function, bit set in legal and no-op function masks 

ACP function, bit set in legal and ACP function masks 

- special case, bit set only in ACP function mask, but not legal 
- special case, bit set anly if diagnostic support in system and 
driver 


Nn 
awn a a ct 
| 


Nn 
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Table 4-8 
Mask Word Bit Settings for Unit Record Devices 


E Bit RSX-11M-PLUS Related Symbolic 


0 Cc IO.KIL 
l t IO.WLB 
2 t IO.RLB 
3 c IO. ATT 
4 c I0.DET 
5 c I0.STC 
6 
7 sa IO.CLN 
8 sd Diagnostic 
9 a IO.FNA 
10 a I0O.ULK 
Ly a IO.RNA 
12 a IO. ENA 
13 a I0.ACR 
14 a IO.ACW 
15 a IO.ACE 
16 a IO. DAC 
17 a IO. RVB 
18 a I0O.WVB 
19 a IO. EXT 
20 a IO.CRE 
Zt a IO. DEL 
22 a IO0.RAT 
23 a IO.WAT 
24 a ITO. APC 
25 
26 
27 
28 
29 


- transfer function, bit set only in legal function mask 

- control function, bit set in legal and control function masks 
~ no-op function, bit set in legal and no-op function masks 

ACP function, bit set in legal and ACP function masks 

- special case, bit set only in ACP function mask, but not legal 
- special case, bit set only if diagnostic support in system and 
driver 


Nn 
aoeoardac 
t 


n 
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4.4.4 The Unit Control Block (UCB) 
Figure 4-5 is a layout of the UCB (a variable-length control block). 
One UCB exists for each physical device-unit generated into a system 


configuration. For user-added drivers, this control block is defined 
as part of the source code for the driver data structure. 


The fields! in the UCB are described below: 
U.UAB (0) 
Driver access: 
Initialized, not referenced. 
Description: 
For terminal UCBs only. It is required only if accounting 
support is on the system (ASSCNT is defined) but may be 


present if accounting support is not on the system. This 
value is used to access the user accounting block in 


secondary pool. 


U.MUP 
Driver access: 
Not initialized, not referenced. 
Description: 
For terminal UCBs only. Bits 1 to 4 contain an index to a 
table which contains the address of CLI Parser Block (CPB) 
for the current CLI; the remaining bits are used for other 
terminal specific features and are defined as follows: 
UM.OVR Override CLI indicator 
UM.CLI CLI indicator 
UM. DSB Terminal diabled because CLI eliminated. 
UM.NBR No broadcast 
UM. CNT Continuation of command line in progress 
UM.CMO Command is in progress from this terminal 
UM.SER Terminal is in serial mode 
UM. KIL TTDRV should tell MCR to flush all pieces of 
a continued command if the user types CTRL/C. 
U.LUIC 


Driver access: 


Not initialized, not referenced. 


Description: 


For terminal UCBs only, and only in multiuser’ systems: the 
logon UIC of the user at the particular terminal. This 
offset must exist for any device on a multiuser system for 
which the DV.TTY bit is set. This word is altered by logging 
into the system. 


l. Parenthesized contents following the symbolic offset indicate the 
value to be initialized in the data base source code. 
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U.OWN (1) 
Driver access: 
Initialized, not referenced. 


Description: 


Only in multiuser systems: the UCB address 


terminal for allocated devices. 


of the 


fa de 8 SS Gere yoke = = “] 
U.UAB [ User Account Block { 10 
U.MUP! Multiuser flags and CLI pointer 6 


poe ee 1 


u.Luic! 
U.OWN 
U.DCB 


U.RED 


U.STS 


ULUNIT 
i P fl i ‘ 

U.CW1 Characteristics word 1 

U.CW2 Characteristics word 2 

U.CW3 Characteristics word 3 

U.CW4 Characteristics word 4 

" devices 

U.SCB Pointer to SCB 20 

U.ATT TCB address of attached task 22 

U.BUF Buffer relocation bias 24 
U.BUF+2 Buffer address 26 


U.CNT Byte count 30 


U.CTL 


16 Alt 


U.UBX2 | Pointer to the UCB extension in secondary pool | 32 


Device- 


dependent 


° 


| storage | 


1. This offset appears only for terminal devices (that is, devices that have DV.TTY set) 


in multiuser systems. 


2. This offset appears only for those devices that have DV.MSD set. 
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Figure 4-5: Unit Control Block 


owning 


PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER 


U.DCB (pointer to associated DCB) 


Driver access: 


Initialized, not referenced. 


Description: 


This word is a pointer to the corresponding device control 
block. Because the UCB is a key control block in the I/0 
data structure, access to other control blocks usually occurs 
by means of links implanted in the UCB. 


U.RED (pointer to start of this UCB (.-2)) 


Driver access: 


Initialized, not referenced. 


Description: 


Contains a pointer to the unit control block to which this 
device-unit has been redirected. This field is updated as 
the result of an MCR Redirect command. The redirect chain 
ends when this word points to the beginning of the UCB itself 
(U.DCB of the UCB, to be precise). 


U.CTL (device-dependent values) 


Driver access: 


Initialized, not referenced. 


Description: 


U.CTL and the function mask words in the device control block 
control QIO directive processing. Figure 4-6 shows the 
layout of the unit control byte. 


U.STS U.CTL 


buc. LGH - Buffer size mask bits for transfer length 


UC.KIL - Unconditional cancel 1/O (1=yes) 
UC.ATT - Attach/detach notification (1=yes) 
UC.PWF - Unconditional call at powerfail (1=yes) 
UC.QUE - Queue to driver bit (1=yes) 

UC.NPR - NPR device bit (1=yes) 

UC.ALG - Alignment (byte or word)(1=no) 
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Figure 4-6: Unit Control Byte 


The driver data base code statically establishes this bit 
pattern. Any inaccuracy in the bit setting of U.CTL produces 
erroneous I/O processing. Bit symbols and their meanings are 
as follows: 


UC.ALG - Alignment bit. 
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If this bit is 0, then byte alignment of data buffers is 
allowed. If UC.ALG is 1, then buffers must be word-aligned. 


UC.ATT — Attach/Detach notification. 


If this bit is set, then the driver is called when SGTPKT 
Processes an Attach/Detach I/0 function. Typically, the 
driver does not need to obtain control for Attach/Detach 
requests, and the Executive performs the entire function 
without any assistance from the driver. 


UC.KIL - Unconditional Cancel I/0 call bit. 


If set, the driver is called on a Cancel I/O request, even if 
the unit specified is not busy. Typically, the driver is 
called on Cancel I/O only if an I/O operation is in progress. 
In any case, the Executive flushes the I/O queue. 


UC.QUE - Queue to-driver bit. 


If set, the QIO directive processor calls the driver at its 
I/O initiation entry point without queuing the I/O packet. 
After the processor makes this call, the driver is 
responsible for the disposition of the I/0 packet. 
Typically, the processor queues an I/O Packet before calling 
the driver, which later retrieves it by a call to S$GTPKT. 


The most common reason for a driver to examine a packet 
before queuing is that the driver employs a special user 
buffer, other than the normal buffer used in ae transfer 
request. Within the context of the requesting task, the 
driver must address-check and relocate such a special buffer. 
See Section 8.3 for an example of a driver that does this. 


On multiprocessor systems, certain restrictions apply to this 
form of I/0 processing. No driver should process an I/0 
packet received directly from the QIO processor without first 
performing a conditional fork operation (that is, call 
SCFORK) to guarantee execution on the correct processor. 
Unless the driver is running on the correct processor, it 
must not process a packet that causes access to the device 
registers. The restriction does not apply if the driver 
merely uses the current task context to map secondary I/0 
buffers and then queues the I/O packet itself. In summary, 
packets received directly from SDRQIO may not be _ processed 
directly unless they cause no activity on the I/O page (and 
thereby do not need to be executed on a particular processor) 
or unless an intervening call to $CFORK has been performed. 


UC.PWF - Unconditional call on power failure bit. 


If set and the unit is on-line, the driver is always to be 
called when power is restored after a power failure occurs. 
Typically, the driver is called on power’ restoration only 
when an I/O operation is in progress. See the discussion in 
Sections 4.3.6 and 4.5 of the entry points in the DDT for 
LOAD and UNLOAD and for controller and unit status change. 


UC.NPR - NPR device bit. 
If set, the device is an NPR device. This bit determines the 


format of the 2-word address in U.BUF (details given in the 
discussion of U.BUF below). 
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UC.LGH - Buffer size mask bits (two bits). 


These two bits are used to check whether the byte count 
Specified in an I/O request is a legal buffer modulus. You 
select one of the values below by ORing into the byte a 0, l, 


2, or 3. 

00 - Any buffer modulus valid 

01 - Must have word alignment modulus 

10 - Combination invalid 

11 - Must have double word-alignment modulus 


UC.ALG and UC.LGH are independent settings. 


NOTE 


UC.ATT, UC.KIL, UC.QUE, and UC.PWF are usually zero, 
especially for conventional drivers. Every driver, 
however, muSt be concerned with its particular values 
for UC.ALG, UC.NPR, and UC.LGH. The driver is 
totally responsible for the values in these bits, and 
erroneous values are likely to produce unpredictable 
results. 


U.STS (0) 
Driver access: 
Initialized, not referenced, 
Description: 
This byte contains device-independent status information. 


Refer to the UCBDFS$ macro definition in Appendix A. Figure 
4-7 shows the layout of the unit status byte. 


U.STS U.CTL 


Unused bits are reserved 
for system use and expansion. 


US.MDM - Marked for dismount (1=yes) 
US.FOR - Mounted as foreign volume (O=yes) 
US.MNT - Volume is mounted (1=no) 
US.BSY - Device-unit busy (1=yes) 


a 
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Figure 4-7: Unit Status Byte 


US.MDM, US.MNT, and US.FOR apply only to mountable devices.t 


l. If your user-written driver services a mountable device, refer to 
Section 4.5.9 for information on volume valid processing. 
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The bit meanings are as follows: 
US.BSY 
If set, device-unit is busy. 
US.MNT 
If set, volume is not mounted. 
US.FOR 
If set, volume is mounted foreign. 
US.MDM 
If set, device is marked for dismount. 
U.UNIT (unit number) 

Driver access: 
Initialized, read-only. 

Description: 
This byte contains the physical unit number of the 
device-unit serviced by this UCB. If the controller for the 
device supports only a single unit, the unit number is always 
zero. 


NOTE 


This is the physical unit number of the device and 
not the logical unit number. The range of this 
number is from zero to n where n is device-dependent. 
The logical designation DBO: does not necessarily 
imply a zero in this byte. 


UsST2 (US. OFL) 
Driver access: 
Initialized, not referenced. 
Description: 


This byte contains additional device-independent status 
information. Different parts of the system set and clear 
these bits. The layout of the unit status extension byte is 
shown in Figure 4-8, 


U.ST2 U.UNIT 


Unused bits are reserved 
for system use and expansion. 


US.OFL - Unit offline (1=yes) 
US.RED - Unit redirectable (1=no) 
US.PUB - Unit is public device (1=no) 
US.UMD - Unit attached for diagnostic s (1=yes) 
US.PDF - Privileged diagnostic 
functions only (1=yes) 
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Figure 4-8: Unit Status Extension 2 
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The bit meanings are as follows: 
US.OFL=1 


If set, the device is off-line (that is, not in the 
configuration). This bit should be initialized to l. 


US. RED=2 

If set, the device cannot be redirected. 

US. PUB=4 

If set, the device is a public device. 
US.UMD=10 

If set, the device is attached for diagnostics. 
US. PDF=20 


If set, this unit can be used for a privileged diagnostic 
function only. 


U.CWl (device-specific characteristics) 
Driver access: 
Initialized, not referenced. 
Description: 


The first of a 4-word continuous cluster of device 


characteristics information. U.CWl and U.CWw4 are 
device-independent, whereas U.CW2 and U.CW3 are 
device-dependent. The four characteristics words are 


retrieved from the UCB and placed in the requester's buffer 
on issuance of a Get LUN information (GLUNS) Executive 
directive. It is your responsibility to supply the contents 
of these four words in the assembly source code of the data 
structure. 


U.CWl is defined as follows. (If a bit is set to 1, the 
corresponding characteristic is true for the device.) 


DV.REC=1 
Record-oriented device 
DV.CCL=2 
Carriage-control device 
DV. TTY=4 


Terminal device. If DV.TTY is set, then the UCB contains 
extra cells (for U.LUIC, U.CLI, and optionally U.UAB). 


DV. DIR=10 
Directory device 
DV.SDI=20 


Single directory device 
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DV.SQD=40 

Sequential device 

DV.MSD=100 

Mass Storage device 

DV. UMD=200 

Device supports user-mode diagnostics 
DV. EXT=400 

Unit is on an extended 22-bit controller 
DV. SWL=1000 

Unit is software write-locked 

DV. ISP=2000 

Input spooled device 

DV. OSP=4000 

Output spooled device 

DV. PSE=10000 


Pseudo device. If this bit is set, the UCB does not extend 
past the U.CWl offset. 


DV.COM=20000 
Device mountable as a communications channel 
DV.F11=40000 
Device mountable as a FILES-11 device 
DV.MNT=100000 
Device mountablel 
U.CW2 (device-specific characteristics) 

Driver access: 
Initialized, read-write. 

Jescription: 


Specific to a given device driver (available for working 
storage or constants) .2 


l. If your user-written driver services a mountable device, refer to 
Section 4.5.9 for information on volume valid processing. 


2. An exception is that, for block-structured devices, U.CW2 and U.CW3 
may not be used for working storage. In drivers for block-structured 
devices (disks and DECtape), these two words must be initialized to a 
double-precision number giving the total number of blocks on the 
device. Place the high-order bits in the low-order byte of U.CW2 and 
the low-order bits in U.CW3. 


PROGRAMMING SPECIFICS FOR WRITING AN I/0 DRIVER 


U.CW3 (device-specific characteristics) 
Driver access: 
Initialized, read-write. 


Description: 


Specific to a given device driver (available for working 
storage or constants) .1 


U.CW4 (device-specific characteristics) 


Driver access: 
Initialized, read-only. 

Description: 
Default buffer size in bytes. This word is changed by a 


system command (SET with the /BUF keyword). The value in 
this word effects FCS, RMS, and many utility programs. 


U.SCB (SCB pointer) 
Driver access: 
Initialized, read-only. 


Description: 


This field contains a pointer to the status control block for 
this UCB. In general, R4 contains the value in this word 


when the driver is entered by way of the driver dispatch 
table, because service routines frequently reference the SCB. 


U.ATT (0) 
Driver access: 
Initialized, not referenced. 


Description: 


If a task has attached itself to the device-unit, this field 
contains its task control block address. 


U.BUF (reserve two words of storage) 


Driver access: 


Not initialized, read-write. 


l. An exception is that, for block-structured devices, U.CW2 and U.CW3 
may not be used for working storage. In drivers for block-structured 
devices (disks and DECtape), these two words must be initialized to a 
double-precision number giving the total number of blocks on the 
device. Place the high-order bits in the low-order byte of U.CW2 and 


the low-order bits in U.CW3. 
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Description: 


U.BUF labels two consecutive words’) that serve as a 
communication region between S$GTPKT and the driver. If a 
nontransfer function is indicated (in D.MSK), then U.BUF, 
U.BUF+2, and U.CNT receive the first 3 parameter words from 
the I/O Packet. 


For transfer operations, the initial format of these _ two 
words depends on the setting of UC.NPR in U.CTL. The driver 
does not format the words; all formatting is completed 
before the driver receives control. The format is determined 
by the UC.NPR bit, which is set for an NPR device and reset 
for a program-transfer device. 


The format for program-transfer devices is identical to that 
for the second two words of I.IOSB in the I/O Packet. See 
Section 4.4.1 for a description of I.IOSB in the I/O packet. 


In general, the driver does not manipulate these words’ when 
performing I/0 to a program-transfer device. Instead, it 
uses the Executive routines Get Byte, Get Word, Put Byte, and 
Put Word to effect data transfers between the device and the 
user's buffer. 


For NPR device drivers, these two words represent what’ the 
driver uses to initiate the transfer operation. For both 
UNIBUS and MASSBUS NPR devices, word 2 contains the low-order 
16 bits of the physical address. For a UNIBUS NPR device, 


bits 4 and 5 in word 1 are memory extension bits; for a 
MASSBUS NPR device (the KS.MBC bit is set), bits 0 through 5 
are the memory extension bits. Et is the driver's 


responsibility to set the function code, interrupt enable, 
and go bits. This action must be accomplished by a Bit Set 
(BIS) operation so that the extension bits are not disturbed. 
The driver must move these words into the device control 
registers to initiate the I/O operation. 


For a typical UNIBUS NPR device driver, the word layout is as 


follows: 

Word 1 

Bit: 0 Go bit initially set to zero 
Bits. 1,273 Function code--set to zeros 
Bits 4,5 Memory extension bits 

Bits 6 Interrupt enable--set to zero 


Bits 7 through 15 Zero 

Word 2 

Bits 0 through 15 Low-order 16 bits of physical address 

The construction of U.BUF, U.BUF+2, and U.CNT occurs only if 
the requested function is a transfer function; if it is not, 
these three words contain the first three words of the I/0 


Packet. 


The details of the construction of the Address Doubleword 
appear in Section 7.2. 
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U.CNT (reserve one word of storage) 
Driver access: 
Not initialized, read-write. 
Description: 
Contains the byte count of the buffer described by U.BUF. 
The driver uses this field in constructing the actual device 
request. 
U.BUF and U.CNT keep track of the current data item in the 
buffer for the current transfer (except for NPR transfers). 
Because this field is being altered dynamically, the I/0 
Packet may be needed to reissue an I/0 operation (for 
instance, after a powerfail or error retry). 
U.UCBX 
Driver access: 
Not initialized, not referenced 
Description: 
This field contains a pointer to the UCB extension in 
secondary pool for mass _ storage devices with DV.MSD set, 


(DV.MSD=1). 


For information on formatting, see the description of the 
UCBDFS macro. 


U.PRM (Device-dependent words) 
Driver access: 
Not initialized, read-write. 
Description: 


The driver establishes this variable-length block of words to 


suit device-specific requirements. For example, a disk 
driver uses the first words to store the disk geometry as 
follows: 

-BLKB 1 OF SECTORS PER TRACK 


7# 
-BLKB 1 ;# OF TRACKS PER CYLINDER 
. BLKW 1 7# OF CYLINDERS PER VOLUME 


The driver can call the $CVLBN routine (described in Chapter 
7) to convert a logical block number to a disk address based 
on the values in U.PRM and U.PRM+2. 


4.4.5 The Status Control Block (SCB) 


Figure 4-9 is a layout of the SCB. The SCB contains the context for a 
unit operation and describes the status of a unit that can run in 
parallel with all other units. 
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S.LHD 


Input/Output 


Queue Listhead 2 


S.URM! Fork UNIBUS Run Mask re 


S.ROFF 2/S.RCNT 2 JOffset to Device Registers | Number of Bytes to Copy] 


S.FRK 


S.KS5 


S.PKT 


S.CTM/S.ITM 


S.STS/S.ST3 


S.ST2 


S.KRB 


Ta eet he wey ee af tere oo ates Ce 
S.EMB2 | Error Message Block Pointer 7 
S.KTB? r KRB Address 0 | 
PS ee Se Se ee ee = 
KRB Address 1 

ty te eee A ree J 

e 

e 

e 
[ KRB Address n 1 
Pe Sa ae ; 
Me see ees Hee ee es ee | 


If the symbols below are defined at system generation time, 
the related cells marked with a number appear in the structure. 


| Multiprocessor support (M$$PRO) 
2 Appears only if driver supports error logging 


31 the system has multiaccess device support (M$$ACD) 
and the driver is multiaccess (S2.MAD) 
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Figure 4-9: Status Control Block 


The fizlds! in the SCB are described as follows: 


1. Par2nthesized contents following the symbolic offset indicate the 
value to be initialized in the data base source code. 
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S.LHD (first word equals zero; second word points to first) 


Driver access: 


Initialized, not referenced. 


Description: 


Two words forming the I/O queue listhead. The first word 
points to the first I/O Packet in the queue, and the second 
word points to the last I/O Packet in the queue. If the 
queve is empty, the first word is zero, and the second word 
points to the first word. 


S.URM (controller UNIBUS run mask) 


S.FRK 


S.KS5 


Driver access: 


Initialized, not referenced. 


Description: 


This word appears only in a multiprocessor system (that is, 
MSSPRO is defined). It contains a UNIBUS run mask that 
defines the UNIBUS run to which the currently assigned 
controller is attached. When controller assignment is made, 
this cell is set from K.URM. For the purposes of running a 
driver on the correct processor, S.URM is used exclusively 
and independently of the value of S.KRB or K.URM. If S.KRB 
is not equal to zero, and if S.URM is not equal to K.URM (an 
unusual situation), then the driver must properly handle the 
fact that it will run on a different processor from the one 
its currently assigned KRB would normally warrant. It is 
possible that the processor on which the driver will run has 
the CSRs at a different location from that stored in the 
current KRB. ADJACENCY WITH THE FORK BLOCK IS ASSUMED! 


(reserve four words of storage) 


Driver access: 


Initialize words to zero, not referenced. 


Description: 


(0) 


The four words starting at S.FRK are used for fork-block 
storage if and when the driver deems it necessary to 
establish itself as a Fork process. Fork-block storage 
preserves the state of the driver, which is restored when the 
driver regains control at fork level. This area is 
automatically used if the driver calls S$FORK. The Fork 
Processor also depends on the adjacency of S.URM and S.KS5 if 
the required support is generated into the system. 


Driver access: 


Initialized, not referenced. 
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Description: 


This word contains the contents of KISAR5 necessary to 
correctly alter the Executive mapping to reach the driver for 
this unit. It has no meaning for a driver that is not 
loadable. It is set by LOAD, and whenever a fork block is 
dequeued and executed, this word is unconditionally jammed 
into KISAR5. ADJACENCY WITH THE FORK BLOCK IS ASSUMED! 


S.PKT ‘reserve one word of storage) 
Driver access: 
Not initialized, read-only. 
Description: 


Address of the current I/O Packet established by SGTPKT. The 
Executive uses this field to retrieve the I/O Packet address 
upon the completion of an I/O request. S.PKT is not modified 
after the packet is completed. 


S..CTM- 0) 
Driver access: 
Not initialized, read-write. 
Description: 


RSX-11M-PLUS supports device timeout, which enables a_ driver 
to limit the time that elapses between the issuing of an I/O 
operation and its termination. The current timeout count (in 
seconds) is typically initialized by moving S.ITM (initial 
timeout count) into S.CTM. The Executive clock service (in 
module TDSCH) examines active times, decrements them, and, if 
they reach zero, calls the driver at its device timeout entry 
point. 


The internal clock count is kept in 1-second increments. 
Thus, a time count of 1 is not precise because the internal 
clocking mechanism is operating asynchronously with driver 
execution. The minimum meaningful clock interval is 2 if you 
intend to treat timeout as a consistently detectable error 


condition. If the count is zero, then no timeout occurs; a 
zero value is, in fact, an indication that timeout is not 
operative. The maximum count is 250. The driver is 
responsible for setting this field. Resetting occurs at 


actual timeout or within $FORK and SIODON. 
S.ITM ‘initial timeout count) 
Driver access: 
Initialized, read-only. 
Description: 


Contains the initial timeout value that the driver can load 
into S.CTM to begin device timeout. 
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S.STS (0) 
Driver access: 
Initialized, not referenced. 
Description: 


Establishes the controller as busy/not busy (nonzero/zero). 
This byte is the interlock mechanism for marking a driver as 
busy for a specific controller. The byte is tested and set 
by SGTPKT and reset by SIODON. 


S.ST3 (driver-specific status byte) 


Driver access: 


Initialized, referenced by driver for synchronization. 
Description: 


This status byte is reserved for driver-specific status bits 
concerning driver-executive or driver-driver communication. 
Figure 4-10 shows the layout of this byte. 


S.ST3 (S.STS) 


15 8 
Reese ee Sere 


S3.DRL - Multiaccess drive in released state 

S3.NRL - Driver should not release drive 

S3.SIP - Seek in progress on drive 

S3.ATN - Driver must clear attention bit 

S3.SLV - Device uses slave units 

S3.SPA - Port ‘A’ spinning up 

S3.SPB - Port ‘B’ spinning up 

S3.O0PT - Seek optimization enabied (1 yes) 
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Figure 4-10: Controller Status Extension 3 


The following are the descriptions for the currently defined 
bits. All currently defined bits are used by mass storage 
devices. 


53.DRL=1 


If this bit is set, the drive is in the released state. 
Drivers that support dual-access (dual-port) operation set 
this bit after completion of the release command by the 
drive. The Executive routines Request Controller for Control 
Function (S$RQCNC) and Request Controller for Data Transfer 
(SRQOCND) test this bit to decide whether the drive is ina 
released state and whether the Executive should attempt load 
balancing by switching ports. 
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S3.NRL=2 


If this bit is set, a driver does not release the drive. 
This bit exists solely for DIGITAL to maintain the device and 
to debug the driver. Drivers that support dual-access 
(dual-port) operation examine this bit and, if it is set, do 
not issue the release command to the drive and do not set the 
S3«<DRE ‘bit. If this bit is set, reconfiguration dual-port 
activity (that is, port on-line and off-line operations) will 
not function properly. 


S3.SIP=4 


If this bit is set, the drive has a seek in progress. A 
driver that supports overlapped seek operations examines this 
bit to keep track of whether the drive is seeking. For a 
driver that does not support overlapped operations but does 
Support error logging (that is, cassette and magtape), this 
bit is set to indicate that a positioning operation is in 
progress. 


S3.ATN=10 


This bit is used only by MASSBUS’ devices. The Executive 
common interrupt module DVINT checks this bit; if it is set, 
then the driver must clear the attention bit in the Attention 
Summary Register. If this bit is not set, DVINT itself 
clears the attention bit in the Attention Summary Register. 


S3.SLV=20 


If this bit is set, the device connects to slave units. 
Certain devices, such aS magnetic tape controllers attached 
to a MASSBUS controller, can in turn have units attached to 
them. These units are referred to as slave units. Thus, if 
this bit is set, the SCB describes a tape controller to which 
Slave units can be attached. 


S3.SPA=40 
If this bit is set, port A on this unit is spinning up. 
$3.SPB=100 
If this bit is set, port B on this unit is spinning up. 
S$3.OPT=200 
If this bit is set, seek optimization is enabled for this 
device. SGTPKT uses this bit to determine whether 
optimization is to be used. An MCR SET command can set. and 
clear this bit. If you select seek optimization support for 
a Digital-supplied device during system generation, SYSGEN 
sets this bit in that device SCB when it creates the Cevice 
data base structures. 
S.ST2 (sontroller status extension) 

Driver access: 
Initialized. 

Description: 


This status word defines certain status conditions for the 
controller-unit combination. Figure 4-11 shows the layout of 


this word. 
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S.ST2 


15 8,7 é 0 

PRR SEGERRER EERE ee 
for system use and expansion. 
S2.EIP - Error in progress (1 = yes) 
S2.ENB - Error logging enabled (0 = yes) 


S2.LOG - Error logging supported (1 = yes) 
S2.MAD - Multiaccess device (1 = yes) 


S2.LDS - Load sharing enabled (1 yes) 

S2.OPT - Device supports seek optimization (1 yes) 
S2.CON - Contiguous KRB/SCB allocation (1 yes) 
S2.OP1 - Indicates the type of optimization used 
S2.OP2 - Indicates the type of optimization used 
S2.ACT - Driver has operation (i/O) active (1 yes) 
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Figure 4-ll: Controller Status Extension 2 


DIGITAL has attempted to restrict bits in this word to’ those 
defining system-wide status. Specific bits for driver and 
Executive synchronization or driver internal synchronization 
are allocated from S.ST3. The following are the descriptions 
for the currently defined bits: 


S2.EIP=1 
This bit is reserved for DIGITAL error logging routines. 


S2.ENB=2 

This bit is reserved for DIGITAL error logging routines. 
S2.LOG=4 

This bit is reserved for DIGITAL error logging routines. 
S2.MAD=10 


This bit indicates the presence of the table of KRB addresses 
at the end of the Status Control Block. If this bit is set, 
the device is a multiaccess device and the SCB has a_ KRB 
table containing pointers to the kKRBs of the controllers 
capable of accessing the device. 


52. LDS=40 


This bit enables and disables load sharing for dual-access 
devices. If this bit is set, the Executive may dynamically 
switch ports and therefore alter controller assignment when 
establishing an access path for a driver. If this bit is not 
enabled, the Executive does not alter the current controller 
assignment. This feature permits static controller 
assignment, perhaps for diagnostic operations. 


Devices (such as terminals) with S2.LDS clear have drivers 
that explicitly manage controller assignment. 


S$2.OPT=100 
If this bit is set, this device supports queue optimization. 


This bit, used by S$DRQRQ, determines whether to call the 
block check and convert the LBN routine in the driver. 
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S2.CON=200 


This bit indicates the continuous allocation of the 
controller request and status control blocks. Devices that 
do not support overlapped operation do not require a separate 
SCB for each unit. The KRB and SCB for such devices can be 
contiguous and some fields in the SCB overlap those in the 
KRB. Therefore, the SCB offsets S.CSR, S.PRI, S.VCT, and 
S.CON are valid only for such devices. For these devices, 
S2.CON is set. 


For the layout of the contiguous KRB and SCB, refer to 
Section 4.4.7. 


S2.0P1=400 
S2.0P2=1000 


These bits indicate the type of optimization selected for 
this device. An MCR command can set and clear these bits. 
These two bits give you three options of queue optimization. 
They are as follows: 


S2.0P2,S2.OP1 = 0,0 Nearest cylinder 
S52.0P2,S2.0P1 = 0,1 Elevator 
S2.0P2,S2.0P1 = 1,0 CSCAN 
S$2.0P2,S2.0P1 = 1,1 Reserved 


S2.ACT=2000 


If this bit is set, the driver has active I/0. 
S.KRB (pointer to currently assigned KRB) 


Driver access: 


Initialized, referenced by driver to access the KRB. 
Description: 


This word points to the currently assigned controller request 
block. For non-multiaccess devices, it is set during system 
generation and never altered. For multiaccess devices with 
load-sharing enabled, it may take on the value of one of the 
KRB pointers in the KRB table, S.KTB. If this word has a 
value of zero, then the device has no currently assigned KRB. 
It may, in fact, not have a KRB or CTB at all. Both the null 
driver and virtual terminal driver have no KRB. 


Certain restrictions apply to drivers whose data bases do not 
include KRBs. They will receive powerfail, timeout, and 
cancel calls like any other driver, but the priority will 
always be zero, and the CSR address and controller index 
(where supplied) will be undefined. 


NOTE 


All code that checks S.KRB for a KRB- pointer’ must 
check for a possible zero value and take appropriate 
action. A zero value in S.KRB does not _ necessarily 
mean that a KRB does not exist, but perhaps rather 
that one is not currently assigned. A device which 
has no KRB will not have S2.CON set. 


PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER 


The first cell in the KRB (K.CSR) contains the control and 
Status register (CSR) address for the controller. The offset 
K.CSR will always be zero so that the pointer (S.KRB) will 
always connect directly to the cell containing the CSR 
address. 


S.ROFF This byte is reserved for devices that support DIGITAL error 
logging software. This value is an offset from S.CSR/K.CSR 
to indicate the start of the device registers. It is 
typically zero. 


S.RCNT This byte is reserved for devices that support DIGITAL error 
logging software. It represents the minimum number of words 
of I/O page registers that this device has. 


S.EMB This word is reserved for devices that support DIGITAL error 
logging software. 


S.KTB (KRB addresses) 
Driver access: 
Initialized, not referenced. 
Description: 


This table appears only if the system has multiaccess device 
support (MSSACD is defined) and the device is multiaccess 
(the S2.MAD bit set). 


Every controller to which the unit (unit control block = and 
status control block combination) can communicate is 
represented in this table by a controller request block 
address. The table contains at least two entries, with the 
list terminated by a zero word. For devices with executive 
load sharing supported (S2.LDS set), bit zero of each word is 
an on-line and off-line flag which, when set, indicates that 
KRB is off-line with respect to this SCB and should not be 
considered for controller assignment. Devices with S&2.LDS 
clear have drivers that explicitly manage controller 
assignment. Only the driver may change S.KRB, and it may or 
may not use the low-order bit of the KRB addresses in S.KRB 
as an on-line and off-line flag. When drivers explicitly 
manage controller assignment, system software (other than the 
driver) must not modify S.KRB and must tolerate a 1 in the 
low-order bit of the values in S.KTB. 


4.4.6 The Controller Request Block (KRB) 


Figure 4-12 is a layout of the controller request’ block. One KRB 
exists for each controller. If a controller allows only a single 
operation on a single unit at a time, then the driver can allocate the 
controller request block and the status control block in continuous 
space. With such continuous allocation, all offsets commonly used _ by 
the driver are referenced by their S.xxx forms. The system will still 
use the offset S.KRB and the K.xxx forms for all references. Refer to 
Section 4.4.7 for the continuous SCB/KRB allocation. 
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a mate et fe 


Driver dependent storage 


K.PRM 
K.CRQ ! Controller request queue listhead - 
K.URM !>2 L. _____ Controller UNIBUS run mask ee 
e 
e 
e 
3 
22-bit 
Working 
3 Storage 


Area 


KE.RHB 3 11/70 UMR/RHBAE offset 
Start of UCB table 
4 UCB address physical unit 0 


4 UCB address physical unit n 


1 1f cont quous allocation of KRB and SCB is used (that is, if S2.CON is set), this field overlaps the !/O request queue. 
2 This field is for multiprocessor support (M$$PRO is defined). 
3 This area is for 11/70 extended memory support (M$$EXT is defined). 

The area extends in a negative direction from the start of the UCB Table. 
4 If KS.LCB is set, then this table appears (allows overlapped function interrupts). 
5 The S.xxx forms of these offsets are valid only for devices that perform a single operation on a 

controller at a time. For such devices, S2.CON is set and the SCB and KRB are allocated in a contiguous area. 

See Figure 4-7 for the contiguous SCB/KRB structure. 
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Figure 4-12: Controller Request Block 


The fields! in the KRB are described as follows: 


1. Parenthesized comments following the symbolic offset indicate the 
value to be initialized in the data base source code. 
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K.PRM (device-dependent storage) 


K. PRI 


Driver access: 


Initialized, read-write. 


Description: 


LOAD does not relocate any addresses in this area. 


(device priority) 


Driver access: 


Initialized, read-only. 


Description: 


Contains the priority at which the device interrupts. Use 
symbolic values (for example, PR4) to initialize this field 
in the driver data source code. These symbolic values are 
defined by issuing the HWDDFS$ macro (refer to the sample data 
base in Chapter 8 and to the listing of the HWDDFS$ macro). 


K.VCT (interrupt vector divided by 4) 


Driver access: 


Initialized, not referenced. 


Description: 


Interrupt vector address divided by 4. Because you can use 
the CON task to change the vector value, you need not be 
overly concerned with initializing K.VCT to the correct 
value. If K.VCT equals zero, then neither LOAD nor UNLOAD 
takes any vector action. In particular, LOAD does not create 
any interrupt control block linkage for this KRB. 


K.CON (controller number times 2) 


Driver access: 


Initialized, read-only. 


Description: 


Controller number multiplied by 2. Drivers that support more 
than one controller use this field. A driver may use K.CON 
to index into a controller table created in the driver data 
base source code and maintained internally by the driver 
itself. By indexing the controller table, the driver can 
service the correct controller when a device interrupts. 


Because this number is an index into the table of addresses 
in the CTB, its maximum value is limited by the value of 
L.NUM in that CTB. 
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K.IOC (0) 
Driver access: 
Initialized, not referenced. 
Description: 


This is an I/O count used by the system to keep track of how 
busy the controller is. The value is related to the number 
of outstanding requests queued for this controller. This is 
a weighted number to be used only by the system to judge the 
relative activity of one controller with respect to another. 


K.STS (controller-specific status) 
Driver access: 
Initialized, not referenced. 
Description: 


This word is used as aestatuS word that concerns’ the 
controller. Figure 4-13 shows the layout of the controller 


Status word. 


K.STS eed 


15 8,7 0 
ale tee tae Unused bits are reserved 

SESE for system use and expansion. 
KS.OFL - Controller offline 
KS.MOF - Controller marked for offline 
KS.UOP - Supports overlapped operation 
KS.MBC - Device is a 22-bit MASSBUS controller 
KS.SDX - Seeks allowed during data transfers 
KS.POE - Parallel operation enabled 
KS.UCB - UCB table present 
KS.DIP - Data transfer in progress 
KS.PDF - Privileged diagnostic functions only 


KS.EXT - Extended 22-bit UNIBUS controller 
KS.SLO - Controller is slow coming online 
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Figure 4-13: Controller Status Word 


All undefined bits are reserved for use by DIGITAL. 
Currently defined bits are: 


KS. OFL=1 


The Executive reconfiguration routines set this bit to place 
the controller off-line and clear the bit to place the 
controller on-line. The bit is used in conjunction with 
KS.PDF to denote transition states. If a request is made to 
assign a unit to the controller and this KS.OFL is set (and 
no other on-line controller is found), the request terminates 
with the IE.OFL error and a return is made to the driver I/0 
initiation entry point to get a new packet. 


The driver data code should initialize this bit to l. 
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KS .MOF=2 


If this bit is set, the unit/controller is in the process of 
becoming offline. 


KS.UOP=4 


This bit indicates whether the controller supports unit 
operation in parallel and requires synchronization. If this 
bit is set, each unit attached to the controller is capable 
of operating independently. Therefore, the KRB contains a 
UCB table holding the UCB addresses of each independent unit. 


KS .MBC=10 


If this bit is set, the device is a 22-bit MASSBUS controller 
and does not use UNIBUS mapping registers (UMRS) but has 2 
extra registers to describe a 22-bit address. If these 
registers exist, the offset to the first of them (RHBAE) is 
in the cell KE.RHB. These registers can be found by using 
the contents of KE.RHB in conjunction with the contents of 
S.RCNT. The Executive on-line reconfiguration code calls the 
common interrupt controller status change routine (in the 
module DVINT) which dynamically sets or clears this bit 
during controller processing. 


KS ..SDX=20 


If this bit is set, the controller allows seek operations to 
be initiated while a data transfer is in progress. (Some 
types of disks, Such as the RKO6 and RKO7, support overlapped 
seek operations but do not allow a seek to be initiated if a 
data transfer is in progress.) The Executive routines Request 
Controller For Control Function (SRQCNC) and Request 
Controller for Data Transfer (SRQOCND) examine this bit to 
distinguish between the two types of controllers that support 
overlapped seeks. 


KS. POE=40 


If this bit is set, the driver may initiate an I/O operation 
on the controller in parallel with other I/O operations. A 
driver that supports overlapped seek operations checks this 
bit to decide whether it should attempt to perform an I/0 
operation as a seek phase and then a data transfer phase 
(that is, overlapped) or aS an implied seek (that is, 
nonoverlapped). If this bit is set, the driver can then 
attempt the overlapped operation. 


An overlapped driver must check this bit once only for each 
I/O operation. Because this bit can be reset by system 
commands at any time, the driver must not rely on the bit 
value to decide whether, upon being interrupted, the driver 
was attempting a seek operation. The driver must use the 
S2.SIP bit to hold its internal state. 


KS .UCB=100 


This bit indicates the presence of the table of unit control 
block addresses associated with the KRB. If this bit is set, 
K.OFF gives the offset from the beginning of the KRB to. the 
Start of the UCB table. 
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Devices that support unit operation in parallel (for example, 
overlapped seeks) require a mechanism for finding the UCB of 
the unit generating an interrupt. Therefore, if KS.UOP is 
set, a UCB table must exist. If KS.UOP is not set, however, 
a UCB table may still exist because some devices (for 
example, terminal multiplexers) support full unit operation 
in parallel but do not require synchronization. Therefore, 
KS.UCB may be used to determine whether the UCB table exists, 
regardless of whether KS.UOP is set. 


KS .<DIP=200 


If this bit is set, a data transfer is in progress. A driver 
that supports overlapped'seek operation sets or clears this 
bit to indicate to itself and to the Executive common 
interrupt module DVINT whether, after an interrupt, a data 
transfer is in progress. The driver must set or clear this 
bit, Usage of this bit eliminates the need for the software 
to access the device registers to determine what type of 
operation was in progress. 


KS. PDF=4090 

This bit and one KS.OFL bit indicate the reconfiguration 
Status -of the. controller. The Executive reconfiguration 
software accesses both bits to describe the off-line, 


On-line, and transition status of the controller. 


KS.EXT=1000 


If this bit is set, the device is a 22-bit UNIBUS controller 
and does not use UNIBUS mapping registers but has 2 extra 
registers to describe a 22-bit address. If these registers 
exist, the offset to the first of them (BAE) is in the cell 
KE.RHB. These registers can be found by using the contents 
of KE.RHG in conjunction with the contents of S.RCNT. 


KS .SLO=2000 


If this bit is set, the controller requires the use of the 
extended time out feature of the reconfiguration subroutine. 
If this bit iS not set, a controller will transition 
online/offline immediately. 


K.CSR (controller status register address) 
Driver access: 
Initialized, read-only. 
Description: 


Contains the address of the Control and Status Register (CSR) 
for the device controller. Because you can use the CON task 
to change the CSR value, you need not be overly concerned 
with initializing K.CSR to the correct value. The driver 
uses K.CSR to initiate I/0 operations and to access, by 
indexing, other registers that are related to the device and 
are located in the I/O page. This address need not be the 
CSR; it need only be a member of the device's register set. 
The Executive reconfiguration software probes K.CSR to bring 
a controller on-line. (If probing K.CSR yields a nonexistent 
memory trap, the controller will not be brought on-line.) 
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NOTE 


This word is guaranteed to be offset zero for the 
KRB. This assignment means that an RSX-11M-PLUS 
driver can access the CSR by the reference @S.KRB and 
need not use a separate register. 


K.OFF (offset in bytes (from K.CSR) to start of UCB table) 


Driver access: 


Initialized, referenced by interrupt dispatch code. 


Description: 


This word contains the offset to the beginning of the unit 
control block table. When added to the starting address of 
the KRB, it yields the UCB table address. The UNIBUS mapping 
register work area extends in a negative direction from the 
Start of the UCB table. 


The status bit KS.UCB may be used to determine whether’ the 
UCB table exists. A UCB table may exist if KS.UOP is not 
set, since some devices (for example, terminal multiplexers) 
support ful unit operation in parallel with no 
synchronization required. If KS.UOP is set, a UCB table must 
appear (and KS.UCB will also be set). 


K.HPU (highest physical unit number) 


Driver access: 


Initialized. 


Description: 


K.OWN (0) 


This byte contains the value of the highest physical unit 
number used on this controller. 


Driver access: 


Initialized, referenced for actual unit. 


Description: 


This word has three slightly different uses, depending on the 
Particular device. 


l. For controllers which always have only ae Single unit 
connected to them (for example, the line printer), 
K.OWN/S.OWN always points to the UCB of that unit. You 
can use the suc argument in the GTPKT$ macro. to 
Statically initialize this cell in the data base. 


2. For controllers that may have multiple units attached but 
do not support unit operation in parallel (for example, 
the RKO5), K.OWN/S.OWN is set with the currently active 
unit by code generated with the GTPKTS macro suc argument 
set to blank. 


K.CRQ 


K.URM 
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3. For controllers that support unit operation in parallel 
and require synchronization (KS.UOP is set), this is a 
busy/nonbusy interlock for the controller. LE the 
controller is busy for a data transfer, this word 
contains the UCB address of the currently active unit. 
This is true for RH disks such as the RPO6. This word is 
set and cleared by the Request Controller for Control 
Access (S$RQCNC), Request Controller for Data Access 
(SRQOCND), and Release Controller (S$RLCN) routines. 


(first word equals 0; Second word points to first) 


Driver access: 


Initialized, not referenced. 


Description: 


Two words that form the controller wait queue. Fork blocks 
are queued here for driver processes that have requested 
controller access. Driver processes that request access for 
control functions are queued on the front of the list, and 
those that request access for data transfer are queued on the 
end of the list. 


(controller UNIBUS run mask) 


Driver access: 


Initialized, not referenced. 


Description: 


This word appears only in a multiprocessor system (that is, 
MSSPRO is defined). 


It contains a UNIBUS run mask that defines the UNIBUS run to 
which the controller is attached. When controller assignment 
is made, the cell is moved into S.URM for the fork block 
there. This word should not be zero. 


Table cf UCB addresses (offset from K.CSR by K.OFF bytes) 


Driver access: 


Initialized, referenced by interrupt dispatch code. 


Description: 


This table contains the unit control block addresses for the 
units on this controller. Physical unit zero is in the first 
word, unit one is in the second word, and unit n is in word 
n+1. The table has a length of (K.HPU(R?)+1) words. A value 
of zero in this table indicates a physical unit number for 
which no actual physical unit exists. The table is 
terminated by a -l. 


NOTE 


This table exists only for those devices that have 
KS.UCB set. 
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KE.RHB (reserve appropriate amount of storage) 


The UNIBUS mapping register work area extends in a negative 
direction from the start of the unit control block table. 
This work area always appears if the device is an NPR device. 
For devices with either KS.MBC or KS.EXT set, the first word 
is used as the BAE offset for the controller. This word 
value is the offset that, when added to the CSR address 
contained in K.CSR, yields the address of the BAE register on 
the controller. If both KS,.MBC and KS.EXT are clear, the 
device controller uses UMRs. 


4.4.7 Continuous Allocation of the SCB and KRB 


In a configuration where a controller and the Executive supports only 
a single operation on a unit at one time, the driver can allocate 
space for the KRB and the SCB in a continuous area. Some fields of 
the KRB overlap those in the SCB. Although the KRB and SCB in this 
arrangement are contiguous, the system still considers the I/0 data 
Structure to contain a éeKRB. The system will still use the S.KRB 
offset and the K.xxx forms for all references. The driver can 
reference the fields by the S.xxx form of the symbolic offset 
definitions. In such a case, although the physical offsets may differ 
between RSX-11M and RSX-l11M-PLUS systems, correct referencing of many 
locations on both systems is eased. Figure 4-14 shows the physical 
layout of the continuous KRB and SCB allocation. 


4.4.8 Controller Table (CTB) 


Figure 4-15 is a layout of the controller table. You ensure that’ the 
CTB is linked into the system list of controller tables by placing the 
CTB macro immediately before the allocation of the L.LNK word. The 
CTB macro generates a global symbol that links the user-written CTB 
into the system list. 
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SCB 
Offsets 


S.VCT/S.PRI 
S.CON 


S.CSR 


S.LHD 


S.URM! 
S.FRK 


S.KS5 

S.PKT 
S.CTM/S.ITM 
S.STS/S.ST3 
S.ST2 

S.KRB 


KE.RHB 
Start of UCB table 


Figure 4-14: 


KRB 
Offsets 
Ul ea ee A eee 
K.PRM Driver-dependent storage 
K.CRQ Input/output queue listhead 
K.URM! Fork URM 


Fork Link 
Fork PC 
Fork R5 
Fork R4 


22-bit 
Working 
Storage 
Area 


11/70 UMR/RHBAE offset 
UCB address physical! unit 0 
e 


UCB address physical unit n 


' This field is for multiprocessor support (M$$PRO is defined). 
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Continuous KRB/SCB Allocation 
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L.CLK Pe ee) Ty SE et Oe ree ] 


KRB address n 


'The head of the list of controller tables is $CTLST in SYSCM. 

If LS.CIN is set, this cell points to the common interrupt 
address table rather than to the DCB. 

3See Table 4-10 for label XXCTB. 


ZK-267-81 
Figure 4-15: Controller Table 


The fields! in the CTB are described below: 
L.CLK 
Driver access: 
Initialized 
Description: 
This is the clock queue entry for these devices that need a 
Single clock block per generic controller type. It only 
appears if LS.CLK is set. 
L.ICB (reserve one word of storage) 


Driver access: 


Not initialized, not referenced. 


l. Parenthesized contents following the symbolic offset indicate the 
value to be initialized in the data base source code. 
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L.LNK 


L.NAM 


L.DCB 
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Description: 


This word points to the first interrupt control block for 
this type of controller. It is a link and not an address. 
In any system the ICBs must be in an executable pool area. 
In an I and D space multiprocessor system, they must be 
distinct for each processor, since each processor has its own 
local executable pool mapped by KISARO. Since the linkage 
must enter and leave other than the usual Executive kernel 
mapping, the upper 4 bits encode a processor number which may 
be used to enter SK6TAB, and the lower 12 bits form an 
address that has been shifted right once. On other than an I 
and D space multiprocessor system, the upper four bits are 
considered part of the address, which has still been shifted 
right once. 


‘0 or link to next CTB in list) 


Driver access: 


Not initialized, not referenced. 


Description: 


All of the controller tables in the system are linked 
together so they can be found, and they are threaded through 
this first word. A zero link terminates this list. 


A CTB must exist for every physical controller type in the 
system. 


‘2-character ASCII device name) 


Driver access: 


Initialized, read-only. 


Description: 


This 2-character ASCII string is the controller mnemonic used 
to find this controller table from among all the others in 
the system. For the RH11/70 controller, it is RH instead of 
DB, DS, DR, or MM. 


L.NAM must be unique throughout the system, unlike D.NAM in 
the device control block. 


‘DCB address or address of common interrupt table) 


Driver access: 


Initialized, not referenced. 


Description: 


The DCB pointer is used to reach the device control block, 
and thereby the unit control block and driver dispatch table 
for a driver. If LS.CIN is set, L.DCB is a pointer to a 
block that holds the common interrupt address (the address of 
the interrupt dispatch routine in the Executive), and the DCB 
addresses (the addresses of the DCBs for the devices that 
this controller interfaces). This block is called the common 
interrupt table and is shown in Figure 4-16. 
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[—Gommon intrupe Adare +d 0 
1 


1 If LS.CIN is set, L.DCB in CTB points to this structure 
instead of to the DCB. 
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Figure 4-16: Common Interrupt Table and Table of DCB Addresses 


The powerfail entry at offset CI.PWF and the controller 
status change entry at offset CI.KRB are addresses of 
routines built into the Executive and are used instead of the 
entries in a particular driver dispatch table. This allows 
devices that have no DCB (for example, the interprocessor 
interrupt and sanity timer) to still participate in 
reconfiguration. 


At offset CI.KRB is the address of a routine built into the 
Executive for multidriver controllers such as the RH type. 
This routine should set or clear the KS.MBC bit tto indicate 
whether the device iS connected to an RH11 or an RH70. The 
driver checks the KS.MBC bit to determine which addressing 
format to use. If the value at CI.CSR is zero, the Executive 
on-line routines check the existence of a device attached to 
this controller by probing the address at K.CSR. If the 
value is nonzero, it is the address of a routine built into 
the Executive to check device presence. Instead of probing 
the address at K.CSR, the Executive on-line code calls this 
routine, which returns either with the C bit clear if the 
device is present or with the C bit set if the device is not 
present. 


The common interrupt table may have only the common interrupt 
address in those cases in which a DCB does not exist (for 
example, the IIST). If LS.MDC is clear, then only one _ DCB 
address exists. (The zero termination is still necessary.) 
If LS.MDC is set, then more than one DCB address is possible; 
therefore, space should be left for all possible DCB 
addresses (for LOAD) and the table terminated by a Zero, 
followed by a-l. Empty entries in this case are indicated 
by a zero word. LOAD will then enter the DCB addresses’ into 
the table when it loads data structures for drivers. 
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L.NUM tnumber of KRB addresses) 

Driver access: 
Initialized, read only. 

De scription: 
Used by programs that scan the controller tables to compute 
the number of KRB addresses. This value is never zero, since 
without controller request blocks there should be no 
controller table. 
The maximum value for L.NUM depends on the type of device and 
on whether the driver is loadable. For common interrupt 
devices, the value must be less than 17 (decimal). For 
resident drivers and drivers loaded by MCR LOAD, the value 
must be less than 17 (decimal). For drivers loaded by VMR 
LOAD, the value must be less than 17 (decimal) if the data 


base is loadable and less than 129 (decimal) if the data base 
is resident. 


L.STS (generic controller status) 
Driver access: 
Initialized, read only. 
Description: 
The controller table status bits give information about’ the 


Class of controllers. Figure 4-17 shows the layout of this 
byte. 


L.STS L.NUM (1 yes) 


8 
Unused bits are reserved 
for system use and expansion. 
LS.CLK - Clock block allocated 
LS.MDC - Multidriver controller 
LS.CBL - Clock block linked into clock queue 
LS.CIN - Controller uses common interrupt address table 


LS.NET - DECnet device 
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Figure 4-17: Controller Table Status Byte 


The following are the descriptions of these bits: 
LS.CLK=1 


If this bit is set, the controller table has an 8-word clock 
block. 


LS.MDC=2 


If this bit is set, multiple drivers service units attached 
to the associated controller. 


LS.CBL=4 


If this bit is set, the clock block is linked into the clock 
queue. 
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LS.CIN=10 


If this bit is set, the driver is associated with a common 
interrupt controller and must have exactly one interrupt 
vector. The driver is therefore called at the D.VPWF entry 
point only for unit power failure. The Executive uses the 
CI.PWF entry point in the common interrupt entry table for 
controller power failure recovery. In addition, the cell 
L.DCB does not point to the device control block but rather 
to the common interrupt entry table in the Executive. 


L.KRB (KRB addresses of controllers) 
Driver access: 
Initialized once for the controller, not referenced. 
Description: 


A list of the controller request block addresses ordered by 
their respective system-wide controller numbers. This table 
is indexed by the controller index retrieved from the PS word 
immediately after an interrupt. The table is of length 
(L.NUM(R?)) words. While the interrupt routines will not 
have to scan the list in a linear fashion, the only way to 
find all the controller request blocks in the system includes 
a linear scan of all the controller tables. The CTB is 
Static. 


The address of the start of the KRB address list in the CTB 
is the global symbol $xxCTB in the driver dispatch table, 
where xx are the characters comprising the controller 
mnemonic. Because LOAD supplies this address in the DDT when 
it loads the driver, a loadable driver should not specify 
this address in the DDT. 


NOTE 


A KRB address of zero indicates a controller that was 
specified during system generation with no attached 
units. No controller request block for such a 
controller is generated. 


Proper action for drivers to access their list of KRB 
addresses is to retrieve the address of the Start of the KRB 
list in the CTB from the cell in the driver dispatch table 
set up by LOAD (both VMR and MCR). 


4.5 DRIVER CODE DETAILS 


This section describes the specific requirements for driver code. The 
driver code must contain a driver dispatch table which allows the 
Executive to call the driver to perform discrete system functions. If 
the driver needs to access either system structures such as the 
partition and task control blocks or structures within itS own data 
base, it should use the system-wide symbolic offsets rather than the 
real offsets. Because the driver is built with the Executive library 
EXELIB.OLB, the symbolic offsets are automatically defined for the 
driver code. If you want to see the definitions of the symbols in 
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your driver listing, place in your driver source code the _ related 
macro name in a .MCALL directive and invoke the macro. (For your 
convenience, the Source code of the macro calls that define the 
symbols of structures is in Appendix A.) The detailed descriptions of 
the driver data base structures are in Section 4.4. 


4.5.1 Driver Dispatch Table Format 


The driver dispatch table associates the entry points that the 
Executive expects to find in a device driver and the actual locations 
of the routines in the driver code. The DDT also provides a link from 
the driver code to the driver data base. Figure 4-18 shows the format 
of the DDT. Section 4.3.1 describes the DDT$S macro call, which 
automatically generates the DDT. 


All device drivers require a driver dispatch table somewhere in the 
first 4K words of the driver code. Conventionally, the table is 
locatec at the beginning of the code. 


NOTE 


If the length of a driver must exceed 4K 
words (20000 octal bytes), then your 
driver must set up the mapping for the 
second 4K words whenever it is entered; 
and, of course, all entry points must be 
in the first 4K words of the driver. 


The driver must define some labels that the Executive routines and the 
INTSV$ macro call use to access the DDT. Table 4-10 lists these 
labels. which are automatically generated by the DDTS macro call. 
Because these labels do not appear in the DDT itself, their format is 
fixed and they must be specified in the format shown. 


Table 4-9 
Labels Required for the Driver Dispatch Table 


Required Format Meaning 


SyxTBL:: 


Defines the start of the DDT. You’ specify 
this label in the D.DSP word of the DCB of 
resident drivers to link the DCB to the 
DDT; For loadable drivers, the LOAD 
routines use this label to fill in D.DSP. 


XxCTB: Defines the pointer to the table of KRB 
addresses in the CTB of the controller for 
device xx. Because a driver can support 
different types of controllers, there may 
be more than one of this form of label. 
(The DDTS macro supports only one 
controller type.) 


SxxTBE:: Defines the end of the DDT for Executive 


LOAD and UNLOAD routines that scan the DDT. 
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D.VNXC, D.VCHK' Next Command/Optimization Entry Point Address -4 
pees!" anlgcavon en Pantadaress N28 
Interrupt Entry Point Address 0 
° 
For Controller xy ; 
Interrupt Entry Point Address n 
ro) 
7 Generic Controller Name (ASCII) 
Interrupt Entry Point Address 0 
For Controller wz 
Interrupt Entry Point Address n 
eae: Cerne 
= e 
: 
ee eee 
1. These are optional advance driver features 
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Figure 4-18: Driver Dispatch Table Format 


At offsets D.VINI through D.VUCB in the DDT of your driver appear 
labels defining the addresses of the entry points in the driver. As a 
standard procedure, you supply the labels described in Table 4-10 at 
the entry points in the driver code. The formats of the standard 
labels that appear in the DDT are not fixed. Because the Executive 
expects to find the entry point addresses at fixed offsets from the 
start of the DDT and the labels themselves appear in the DDT, you’ can 
change their format if you construct the DDT without using the DDTS 
macro call. (However, other labels that are required in the driver 
code but do not appear in the DDT have a certain, fixed format which 
you must not change. For reference, these fixed format labels are: 


SxxTBL:: 
xxCTB: 

SxxTBE: 
SxxLOA: 
SxxUNL: 
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These fixed-format labels are described elsewhere in this’ chapter.) 
The CDTS macro uses the standard labels but allows you to alter the 
format of some of then. 


At offset D.VINT in the DDT is the name of the controller type that 
the driver supports. (The same name is in the CTB.) If the driver has 
no controller (such as the virtual terminal driver VTDRV), this word 
is zero. The structure allows the driver to Support multiple 
controller types. (The terminal driver supports different controller 
types.) Although the DDT$ macro supports only one controller type, 
there is no restriction on the number of controller types that a 
driver can support. 


After each controller name follows a block of interrupt entry 


addres3es. At location D.VINT+2 begins the first interrupt address 
block, each word of which defines an address to be included in a 
vector for the driver. A zero terminates the block and indicates that 
there ire no more interrupt entry points for the controller. There is 
no res:riction on the number of vectors each controller may have. For 
a Sing:ie interrupt device, location D.VINT+2 (interrupt entry address 
0) is che interrupt address. 


Table 4-10 
Standard Labels for Driver Entry Points 


Entry Point 


XXINI: I/O initiation 

xXCAN: Cancel I/0 

XXCHK: Block check and conversion 
xxOUT: Device timeout 

XX PWF: Power failure 

XXKRB: Controller status change 


xXUCB: Unit status change 


SxxINT:: Interrupt entry point 


l. The characters xx are the 2-character mnemonic. 


The Executive reconfiguration software uses the following rules when 
it accesses the interrupt address block to calculate the vectors for a 
controller. To calculate the first vector address, reconfiguration 
routines access the cell K.VCT (or S.VCT) in the controller request 
block. If K.VCT is not equal to zero, it is multiplied by 4. The 
result is the vector address that will be loaded with the address 
found in interrupt entry point 0. The next interrupt entry point is 
examined. If it is zero, there are no more vectors or interrupt entry 
points for the controller. If it is even, the next vector address is 
the previous one plus 4 and that vector address is loaded with the 
entry point address just examined. 


If an entry point value in the block is odd (bit zero is set), bit 
zero is cleared and the resulting number is an offset to the next 
vector address. To compute the next vector address, the offset is 
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added to the last vector address The next interrupt entry point is 
examined. If it is even, then its value is loaded into the last 
vector address computed. If it is odd, the result is an offset that 
is added to the vector address just computed and the next entry point 
is examined. The computation of vector addresses terminates when’ the 
next entry point is zero. 


The entries shown in Figure 4-19 can be used to calculate the 
interrupt vector addresses when K.VCT equals 300. 


The vectors at 300 and 304 are loaded with addresses xxINl and xxIN2. 
The odd value 7 yields the offset 6 that is added to the last vector 
computed to attain 312. The address xxIN3 in the next interrupt entry 
Point examined is loaded in the vector at 312. A zero word in the 
block shows there are no more vectors or interrupt entry points. 


Following the interrupt entry address block for a controller type is a 
pointer to the KRB table in the CTB. Its label is in the form xxCTB, 
which is used by the INTSV$ macro. This pointer connects .the driver 
code to the driver data base and is the last entry in a block for a 
specific controller. 


A zero terminates the driver dispatch table. The global label in the 
form $xxTBE marks the terminating word in the DDT. 
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Figure 4-19: Sample Interrupt Address Block in the DDT 


4.5.2 I/0 Initiation Entry Point 


The offset D.VINI in the driver dispatch table contains the address of 
this entry point. A driver is called at this entry point at priority 
0 from the Executive routine S$DRORQ in the module DRQIO. A driver 
should call the Executive SGTPKT routine to get an I/O packet to 
process. This action dequeues an I/O request. The following are the 
register conventions when the Executive enters the driver. 


R5 = address of the UCB of the unit for which the Executive has 
queued an I/O packet 


This entry condition pertains unless the driver wants to delay the 
queuing operation. Therefore, if the queue-to-driver bit UC.QUE in 
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the unit status block offset U.CTL is set, the following are _ the 
register conventions. 


RS = UCB address of unit for which a packet has been created 
R4 = SCB address of the related unit 
Rl = address of the I/O packet 


You may find more information on and coding requirements for the 
queue-to-driver operation in the description of the UC.QUE bit in 
Section 4.4.4 and an example of its use in Chapter 8. 


The GTPKTS macro call automatically generates the call to the S$GTPKT 
routine and the code to process the return from $GTPKT. Upon return 
from $3TPKT, the C bit indicates whether there is a packet to process. 


C= i If the C bit is set, the Executive found the controller 
busy, could not dequeue a request, or had to call $FORK 
to have the driver run on the correct processor. 


C = 0 If the C bit is clear, the Executive successfully 
dequeued a packet for the driver and placed it in the 
device's input/output queue. 


If a request was successfully dequeued, the following are the contents 
of the registers: 


R5 = Address of unit control block 

R4 = Address of status control block 

R3 = Controller index 

R2 = Physical unit number of device to process 
Rl = Address of the I/O packet 


If the C bit is set, the driver returns control to the caller (a 
RETURN instruction should be executed). If the C bit is clear, the 
generated code loads the location at offset K.OWN/S.OWN in the 
continuous KRB/SCB with the UCB address of the unit to process. The 
driver may then process the request and activate the device. All 
registers are available to the driver. The driver executes a RETURN 
instruction to transfer control to the system. 


On a multiprocessor system, before returning a packet to the driver, 
SGTPKT calls the conditional fork routine $CFORK to ensure that the 
driver executes on the correct processor. If the current processor is 
the correct processor, SCFORK returns to SGTPKT, and SGTPKT dequeues 
an I/O packet, queues it to the driver, and returns to the driver with 


the C bit clear. Should the current processor not be the correct 
processor, S$CFORK will call $FORK which returns to the driver with the 
C bit set. This action causes the driver to dismiss itself. 


Eventually the fork processor restarts the driver executing on _ the 
correct procesSor. 


4.5.3 Cancel Entry Point 


The offset D.VCAN in the driver dispatch table contains the address of 
this entry point. The Executive routine S$IOKIL in the IOSUB module 
calls the driver at this entry point at device priority. When the 
Executive enters the driver, the following register conventions 
pertain: 


R5 = UCB address 

R4 = SCB address 

R3 = Controller index (undefined if S.KRB equals zero) 
Rl = Address of TCB of current task 

RO = Address of active I/O packet 
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The usage of this entry point is explained in Section 2.2.2. All 
registers are available to the driver. The driver returns control to 
the Executive by executing a RETURN instruction. 


4.5.4 Device Timeout Entry Point 


The offset D.VTIM in the driver dispatch table contains the address of 
this entry point. Routines in the Executive module TDSCH call the 
driver at this entry point at device priority. When the Executive 
enters the driver, the entry conditions are as follows: 


R5 = UCB address 

R4 = SCB address 

R3 = Controller index (undefined if S.KRB equals zero) 
R2 = Address of device CSR 

RO = I/O status code IE.DNR (Device Not Ready) 


The usage of this entry point is explained in Section 2.2.3. All 
registers are available to the driver. The driver returns control to 
the Executive by executing a RETURN instruction. 


4.5.5 Next Command Entry Point 


Ths offset D.VNXC in the driver dispatch table is only applicable to 
the terminal driver. The offset D.VNXC contains the entry point 
address of a routine within the terminal driver which is called from 
the routine S$SNCMD in the Executive module DRSUB. This entry point is 
entered when a task exits whose TI: is set to serial mode. The 
driver then passes the next CLI command to the MCR dispatcher. When 
the Executive enters the driver, the following register conventions 
pertain: 


RO = UCB address of the TI: of the exiting task. 


4.5.6 Queue Optimization Entry Point 


The offset D.VCHK in the driver dispatch table contains the address of 
this entry point. The routine $DRORQ in the Executive's module DRSUB 
calls the driver at this entry point at priority zero. When the 
Executive enters the driver, the following register conventions 
pertain: 


R5 
R]. 


UCB address 
I/O packet address 


If the I/O operation is a data transfer function, the I/0 packet 
contains the starting LBN for the I/O request. The routine at this 
entry point must verify the request is a data transfer function, and 
if it is, the routine must replace the starting LBN with the starting 
cylinder, track, and sector number to perform queue optimization. See 
the routine DBCHK in the module DBDRV for an example of a driver that 
supports queue optimization. 
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4.5.7 Deallocation Entry Point 


The offset D.VDEB in the driver dispatch table contains the address of 
this entry point. This entry point is called at priority zero from 
the routine SFINBF in the Executive module SYSXT after a buffered I/0 
request completes. The driver is expected to deallocate its buffers 
at this entry point. When called, the registers are set up as 
follows: 


RO = address of the first buffer 


All registers are available to the driver. The driver returns control 
to the Executive by executing a RETURN instruction. 


4.5.8 Power Failure Entry Point 


The offset D.VPWF in the driver dispatch table contains the address of 
this eitry point. The routines in the Executive module POWER call the 
driver at this entry point at priority 0 for both unit and controller 
Power failures. The Executive first calls the driver for controller 
power failure with the C bit set. The driver is called in this 
fashio1 once for each controller. The following are the register 


convenzions: 
C bit set (controller power failure) 


R 3 
R2 


CTB address 
KRB address 


tt 


The driver may use all registers. 


After the Executive has called the driver for all related controllers, 
it ca.ls the driver once for each unit power failure at priority 0 
with the C bit clear. The following are the register conventions: 


C bit clear (unit power failure) 
‘ UCB address 
SCB address 
Controller index 


) 


DDD 


one ow 


7 
ay 
4 


For both controller and unit power failures, the driver returns 
control] to the calling routine by executing a RETURN instruction. 


If the driver supports a common interrupt device (that is, the LS.CIN 
bit ir the CTB is set), the driver is called at this entry point only 
for unit power failures. For controller power failures, the Executive 
calls the entry point at CI.PWF in the common interrupt entry table. 
See the description of the offset L.DCB in Section 4.4.8. 


4.5.9 Controller Status Change Entry Point 


The offset D.VKRB in the driver dispatch table contains the address of 
this entry point. The Executive routine $KRBSC in the OLRSR module 
calls the driver at this entry point at priority 0 to put a controller 
on-line or to take a controller off-line. 
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NOTE 


If the controller is a common’ interrupt 
controller (LS.CIN is set), the 
Executive does not call the driver at 
this address (if any) specified in the 
DDT but at the address in the common 
interrupt table labelled CI.KRB. See 
Section 4.4.8. 


The C bit indicates whether the request is for off-line or on-line. 
The following are the register conventions upon entry to the driver. 


R3 

R2 
0(SP) 
2 (SP) 


The C bit 


C 
C 


CTB address for the controller 

KRB address of controller changing status 

Return address for completion 

Return address for caller of the Executive routine 


is set to indicate the requested status change as follows: 


1 On-line to off-line transition 
0 Off-line to on-line transition 


The status change byte S$SCERR is preset as follows: 


SSCERR = 1 


The driver indicates the return status in the S$SCERR byte as follows: 


SSCERR < 0 Operation is not successful and a negative value in 


SSCERR is the I/O error code. Thus, a negative value 
rejects the status change requested by the C bit. 


SSCERR = 1 Operation is’ successful. The driver accepts the 


status change requested. This is the default 
condition. 


All registers are available to the driver. The Executive does not 


change 


t 


he status of the controller until and unless the driver shows 


successful completion of the on-line or off-line request. 


The driver must return immediately by either of the following methods: 


l. 


The driver can indicate the return status immediately and can 
return to the first address on the stack in the normal 
fashion. If the driver accepts the status change, it merely 
executes a RETURN instruction. (The status change byte 
SSCERR has been preset with 1.) If the driver rejects’ the 
status change, it loads the relevant I/O error code into 
SSCERR and executes a RETURN instruction. (The I/O error 
code symbols are listed in an appendix of the IAS/RSX-11 I/0 


Operations Reference Manual.) 


The driver need not indicate the status immediately but 
removes the first address from the stack, saves it, and 
returns immediately to the second address. The driver then 
has 60 seconds to perform its processing, to indicate the 
return status, and to return to the first address. The 
driver can use the offset S.CTM in the status control block 
to time out some operation (Such aS a protocol rundown) = and 
then accept or reject the operation by using SSCERR. 
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If the driver does not return to the first address on the stack, the 
system can be considered to be in an indeterminate state and possibly 
corrupted. The driver must return immediately because status changes 
should not stall the system. The 60-second delay allows a driver time 


to oveicome conditions over which it has little control (such as 
networ! connections). System disk and terminal drivers must indicate 
return status immediately. However, the terminal driver (TTDRV) 


rejects a controller on-line request for a DZ11 multiplexer if some of 
the stetus bits indicate that the device is not a DZ11 or that it is 


broken. 


4.5.10 Unit Status Change Entry Point 


The of*set D.VUCB in the driver dispatch table contains the address of 
this entry point. The Executive routine $UCBSC in the OLRSR module 
calls the driver at this entry point at priority 0O to put ai unit 


on-line or to take a unit off-line. This entry is called once for 
each unit whose status changes. The C bit indicates whether’ the 
reques:: is for on-line or off-line. The following are the register 


conven::ions: 


R»> = Address of UCB or unit changing status 

Rl = Address of SCB of unit 

R3} = Controller index (undefined if S.KRB equals zero) 
O(SP = Return address for driver completion 
2(SP = Return address for caller of the Executive routine 


The C bit is set to indicate the requested status change as follows: 


1 On-line to off-line transition 
0 Off-line to on-line transition 


C 
C 


The st.itus change byte SSCERR is preset as follows: 
S$3CERR = 1 
The driver indicates the return status in the $SCERR byte as follows: 


$3CERR < 0 Operation is not successful and a negative value in 
SSCERR is the I/O error code. Thus, a negative value 
rejects the change requested by the C bit. 


$5CERR = 1 Operation is’ successful. The driver accepts’ the 
status change requested. This is the default 
condition. 


All reyisters are available to the driver. The driver must return 
within 60 seconds. The Executive does not change the status of a unit 
until and unless the driver shows successful completion of the on-line 
or off-line request. 


The driver must return immediately by either of the following methods: 


l. The driver can indicate the return status immediately and can 
return to the first address on the _ stack in the normal 
fashion. If the driver accepts the status change, it merely 
executes a RETURN instruction. (The status change byte 
SSCERR has been preset with 1.) If the driver rejects’ the 
Status change, it loads the relevant I/O error code into 
SSCERR and executes a RETURN instruction. (The I/O error 
code symbols are listed in an appendix of the IAS/RSX-11 I/0 
Operations Reference Manual.) 
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2. The driver need not indicate the status immediately but 
removes the first address from the stack, saves it, and 
returns immediately to the. second address. The driver’ then 
has 60 seconds to. perform its processing, to indicate the 
return status, and to return to the first address. The 
driver can use the offset S.CTM in the status control block 
to time out some operation (such aS a protocol rundown) = and 
then accept or reject the operation by using S$SCERR. 


If the driver does not return to the first address on the stack, the 
system can be considered to be in an indeterminate state and possibly 
corrupted. The driver must return immediately because status changes 
should not stall the system. The 60-second delay allows a driver time 
to overcome conditions over which it has little control (such as 
network connections). System disk and terminal drivers must indicate 
return status immediately. 


4.5.11 Interrupt Entry Point 


Upon an interrupt, control is dispatched to the driver from an 
interrupt vector through an interrupt control block or directly from 
an interrupt vector. A device may have more than one interrupt entry 
point. The entries in the DDT interrupt address block are used to 
initialize either the vector(s) or the interrupt control block with 
the address(es) of the related interrupt entry point(s). (Refer to 
Section 4.5.1 for a discussion of the interrupt address block.) All 
drivers should observe the protocol for handling interrupts introduced 
in Section 1.3 and summarized in Section 4.1. 


If the driver is loadable, it will be called from the interrupt 
dispatch coroutine SINTSI in the Executive. The following are the 
register contents when the driver gets control: 


R4 = Controller index 


Registers R4 and R5 are available to the driver. The driver runs at 
the priority set in the interrupt control block. To dismiss the 
interrupt, a driver executes a RETURN instruction. 


If the driver is resident, it receives control directly from _ the 
interrupt vector. It runs at priority PR7 and the low-order four bits 
of the PS have the controller number of the interrupting device. 
Because the low-order four bits are status bits and almost any 
instruction modifies them, the first operation that should be 
performed is to save the PS. Then, the driver does its processing at 
priority PR7 (saving registers if necessary). After processing, it 
restores the registers (if necessary) and dismisses the interrupt by 
executing an RTI instruction. 


However, all reasonable drivers should use the INTSVS macro call at an 
interrupt entry point. The INTSVS$ macro resolves entry processing for 
both loadable and resident drivers. For loadable drivers, INTSVS$ does 
not generate a call to SINTSV because LOAD eStablishes in the 
interrupt control block the call to the S$INTSI coroutine. The SINTSI 
coroutine saves R4 and R5; sets the priority to that in the interrupt 
control block; and forms the controller index from the PS and stores 
it in R4. (LOAD previously set the priority in the interrupt control 
block based on the value at offset K.PRI in the controller request 
block.) 


For resident drivers, INTSVS generates a call to the SINTSV coroutine, 
which sets the priority to that specified in the INTSVS macro call; 
saves registers R4 and R5; and forms the controller index from the PS 
and stores it in R4. 
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For both loadable and resident drivers, INTSVS generates code to load 
R5 with the UCB address of the interrupting unit. After the INTSVS 
call in the driver code, the following conditions pertain for both 
loadable and resident drivers: 


UCB address of the interrupting unit 
Controller index 


R5 
R4 


The driver may then do the following: 
l. Save extra registers if necessary 
2. Do whatever processing is necessary 


3. Become a fork process to access the data structures or to 
call Executive routines if necessary 


4. Restore the explicitly saved extra registers 


5. Execute a RETURN instruction to the coroutine, which 
dismisses the interrupt 


In summary, then, the INTSVS macro eliminates your having to consider 
the coding differences between a loadable and a resident driver in the 


interrupt service routine. 


4.5.12 Volume Valid Processing 


System--supplied drivers that service mountable devices (those that 
have the DV.MNT bit in the UCB U.CWl word set) take advantage of 
specia.. processing of volume valid for a device. For such devices the 
Execut.ve directive processor DRQIO checks that either of the mounted 
status bits US.MNT or US.FOR in the UCB U.STS word is set. If a 


mounted status bit is not set, DRQIO requires that a device-specific 
bit ca..led volume valid (US.VV) be set or else it rejects the 
direct: ve. If amounted status bit is set, DRQIO does not check the 


volume valid bit. (DRQIO assumes that the MOUNT command properly set 
the volume valid bit.) 


To effectively service a mountable device on the system, a 
user-written driver should perform in one of two ways. First, it can 
take ac'vantage of the volume valid capability in the same way that a 
system-supplied driver does. This processing involves calling the 
SVOLVD routine in the Executive module IOSUB, and handling’ the 
spinnirg-up status bit (US.SPU) and the volume valid bit (US.VV) in 
the UCE status byte U.STS. (For details of this mechanism, refer to 
driver source code supplied on the system.) Second, a user-written 
driver can circumvent the volume valid processing by doing the 
following: 


l. Enable the set characteristics function (I0.STC) for volume 
valid in the DCB legal function mask word 


2. Enable the same function in the DCB no-op function mask work 


3. Statically set the US.VV bit in the UCB in the driver data 
base source code 


The second method allows the device to be successfully mounted = and 
associated with an ancillary control processor without your having to 
include code in the driver to handle US.VV. 


CHAPTER 5 


INCORPORATING A USER-SUPPLIED DRIVER INTO RSX-11M-PLUS 


This chapter describes how to incorporate a uSer-supplied driver into 
an RSX-11M-PLUS system. The material in the chapter depends on your 
having created source code according to the programming specifics 
given in Chapter 4. 


5.1 GUIDELINES FOR INCORPORATING A DRIVER 


The procedures that you follow to incorporate a user-supplied driver 
into RSX-11M-PLUS depend on the type of driver you have. Your driver 
is one of the following types: 


e Loadable driver with a loadable data base 
e Loadable driver with a resident data base 


e Resident driver with a resident data base 


If your driver is loadable with a loadable data base, you may perform 
a system generation to include your driver, or you may incorporate it 
directly into your currently running system. If you want to use a new 
version of a loadable driver with a loadable base, and your driver is 
currently loaded, you must create a new system image file, load the 
new version of the driver into the file, and then bootstrap the new 
system. Refer to Section 5.1.1 if you want to incorporate your driver 
at system generation. Refer to Section 5.1.2 if you want to 
incorporate your driver after system generation. 


If your driver is loadable with a resident data base, or is resident, 
you must perform a system generation because the resident driver 
and/or data base reside in the Executive and must be assembled and 
task built as part of the Executive. Refer to Section 5.1.1 to 
incorporate your driver at system generation. 


Because loadable drivers and loadable data bases can be changed _ and 
reloaded without performing a system generation, loadable drivers with 
loadable data bases are easier to debug and maintain than resident 
drivers and/or resident data bases. 


5.1.1 Incorporating a Driver at System Generation 


If you want to build a loadable driver with a loadable or resident 
data base during system generation, proceed as follows: 


1. Assemble and task build jy our driver to eliminate any assembly 
or Task Builder errors. 


INCORPORATING A USER-SUPPLIED DRIVER INTO RSX-11M-PLUS 


2. Put the MACRO-11 source files containing your driver code and 
data base in UFD [11,10] on the target system disk. The 
driver source file should be named xxDRV.MAC and the data 
base source file should be named xxTAB.MAC, where xx is the 
2-character device mnemonic. Mnemonics for user-Supplied 
devices should begin with the letters J or Q to avoid 
conflict with DIGITAL-supplied devices. 


3. Perform a system generation and choose the Full-functionality 
Executive. Answer the questions concerning user-supplied 
drivers printed during system generation. This procedure 
includes your driver data base in the Executive if it is 
resident and builds your driver task image. A loadable 
driver and data base are loaded into the system image file. 
Refer to Section 5.3 for a description of the system 
generation procedure. 


4. Use CON from MCR to make your devices accessible. Refer to 
Section 5.2.5 for the CON command description. 


If you want to build a resident driver, proceed as follows: 


1. If your driver can run loadable with a loadable data base, 
first build and test it as loadable with a loadable data 


base. 


2. Put the MACRO-11 source files containing your driver code and 
data base in UFD [11,10] on your target system disk. The 
driver source file should be named xxDRV.MAC and the data 
base source file should be named xxTAB.MAC where xx is the 
2-character device mnemonic. Mnemonics for user-sSupplied 
devices should begin with the letters J or Q to avoid 
conflict with DIGITAL-supplied devices. 


3. Perform a system generation. If you want to include a 
resident driver, you must not choose the Full-functionality 
Executive or Executive data space support. Answer’ the 


questions concerning user-supplied drivers printed during 
system generation. This procedure includes your driver and 
data base modules in the Executive. Refer to Section 5.3 for 
a description of the system generation procedure. 


4. Use CON from MCR to make your devices accessible. Refer to 
Section 5.2.5 for the CON command description. 


5.1.2 Incorporating a Loadable Driver with a Loadable Data Base After 
System Generation 


The procedures to incorporate a loadable driver with a loadable data 
base after system generation involve the following steps: 


1. Assemble and task build your driver to eliminate any assembly 
or Task Builder errors. 


2. Put the MACRO-11 source files containing your driver code and 
data base in UFD [11,10] on your target system disk. The 
driver source file should be named xxDRV.MAC and the _ data 
base source file should be named xxTAB.MAC, where xx is the 
2-character devic2 mnemonic. Mnemonics for user-sSupplied 
devices should start with the letters J or Q to avoid 
conflict with DIGITAL-supplied devices. 
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3. Run the system generation procedure and follow the 
instructions in the "Adding a Device" section. (For 
information on invoking the system generation procedure 
(SYSGEN), refer to the RSX-11M-PLUS System Generation and 
Installation Guide). 


The system generation procedure asks you to enter the 
2-character device mnemonic for your driver. Remember, this 
should be the same mnemonic used in the driver and data base 
source file names. 


4. Use the MCR LOA command to link your driver data base _ into 
the system device tables and to load your driver data base 
and driver code. Refer to Section 5.2.4 for the LOA command 
descriptions. 


5. Use CON from MCR to place the controller(s) and unit(s) = on 
line. (CON can also alter vector assignments.) Refer to 
Section 5.2.5 for the CON command descriptions. 


5.2 WHAT THE SYSTEM GENERATION PROCEDURE DOES FOR YOU 


The system generation procedure assembles your driver and data base, 
puts the resulting object modules in the Executive object library and 
task builds your driver. If your driver or its data base is resident, 
the driver and/or data base is included in the Executive. If your 
driver or its data base is loadable, the driver and/or data base is 
loaded into the system image file. You must then make _ the 
controller(s) and unit(s) accessible. 


The commands that the system generation procedure uses to assemble 
your driver and data base, insert your driver and data base modules in 
the library, and task build your driver, are the same commands” that 
you may use to assemble, insert and task build your driver. The 
following subsections explain each of the procedures for incorporating 
your driver. 


5.2.1 Assembling the Driver and Data Base 


The system generation procedure assembles your driver and its data 
base with the following commands: 


MAC>({11,24]xxDRV, [11,34] xxDRV/-SP=[1,1]EXEMC/ML, [11,10]RSXMC/PA:1,xxDRV 
MAC>[(11,24]xxTAB,[(11,34]xxTAB/-SP=[1,1]EXEMC/ML,(11,10]RSXMC/PA:1,xxTAB 


If your driver is resident, these commands are located in the file 
RSXASM.CMD. If your driver is loadable, these commands are located in 
the file xxDRVASM.CMD, where xx is the device mnemonic. 


The commands to the assembler specify as input the Executive macro 
library EXEMC.MLB, the Executive assembly prefix file RSXMC.MAC, and 
either your driver code or driver data base source file (xxDRV.MAC or 
xXXTAB.MAC). EXEMC.MLB contains the macro definitions of structures 
and symbolic offsets that your code may reference. (The source code 
for some of the macro definitions is given in Appendix A.) RSXMC.MAC 
contains symbols defined during system generation and definitions of 
Some macros that your driver may invoke (such as DDTS, GTPKTS$, and 
INTSVS). The assembler looks for the source file of your driver in 
UFD [11,10]. 
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As output, the assembler creates object modules in UFD [11,24] and 
listiny files in UFD [11,34]. The object modules xxDRV.OBJ and 
XXTAB.OBJ will later be put in the Executive object library. You 
should retain the listing files xxDRV.LST and xxTAB.LST for 
documentation and maintenance purposes. 


5.2.2 Inserting the Driver and Data Base Modules in the Library 


After your driver and data base modules have been assembled, the 
driver and data base modules are added to the Executive object 
library. Commands to the Task Builder (described in Section 5.2.3) 
requir: the modules be in this library. 


The system generation procedure uses the following commands to add 
both the driver and its data base to the same library: 


L3R [1,24]RSX11M/RP=[11,24]xxDRV,xxTAB 


The command to LBR adds the object modules of both your driver and its 
data base to the Executive object library RSX11M.OLB, which resides in 
UFD [1,24]. RSX11M.OLB is built from object modules assembled during 
system generation. The /RP switch ensures that any modules of the 
same name are replaced by the recently created modules. If this is 
not the first time you have performed this operation, LBR prints 
messages telling you that it replaced your modules in the library with 
the new versions. 


5.2.3 Task Building the Driver 


After the modules have been added to the Executive object library, the 
system generation procedure task builds your driver and data base. 
The commands for a resident driver are located in the file RSX11M.CMD. 
The commands for a resident data base are located in the file 
RSX11M.CMD on systems without Executive data space support and in the 
file DSP11M.CMD on systems with Executive data space support. 


The commands for a loadable driver are located in xxDRVBLD.CMD where 
xx is the device mnemonic. The following discussion explains each of 
the lines that are contained in the command file for a loadable 
driver: 


1. When the system generation procedure builds your driver, a 
task-image file name and a symbol definition file name are 
specified as MTKB output. The task image and symbol 
definition files are placed in the UFD corresponding to the 
system UIC that will be in effect when the LOA command is 
issued. The file names are both xxDRV, where xx is the 
device mnemonic. The Task Builder produces the output files 
named xxDRV.TSK, xxDRV.MAP, and xxDRV.STB. For example, the 
input supplied to TKB to build the xx device would look like 
the following: 


[1,54] xxDRV/-HD/-MM, [1,34] xxDRV/-SP, [1,54] xxDRV= 
2. No task header is included. The switch /-HD is used, as in 
the previous example. A driver is not really a task, but an 


extension of the Executive, and as such needs no task header. 


3. The switch /-MM must be used in the command line. 
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4. A map file is produced and is useful for debugging. All 
driver map files are written to UFD [1,34]. The switch /-SP 
suppresses automatic spooling to the line printer. 


5. The system generation procedure links your driver to the 
system symbol definition file that contains definitions of 
Executive global symbols. Continuing the example from item 1 
above might give further TKB input that would like this: 


{1,24]RSX11M/LB:xxDRV:xxTAB 
{1,54]RSX11M.STB/SS 


The first line above specifies the library file (/LB) in 
which the input driver object module and the object file for 
the loadable data base can be found. The object module 
specification for the driver always precedes the 
specification for the data base in the TKB command line. 


The second line in item 5, above, indicates that the symbol 
definition file RSX11M.STB is to be searched selectively 
(/SS) for definitions of Executive global symbols. Note that 
the /SS switch must appear in this context. It is never 
omitted. 


6. The system generation procedure links your driver to the 
system library file that defines masks and offsets used in 
the Executive. To continue the example: 


[1,1]EXELIB/LB 
/ 


The single slash begins the option phase of the Task Builder. 


7. The Task Builder is directed not to allocate space for a 
stack within the driver. 


STACK=0 


8. A partition for the driver is specified: 


PAR=DRVPAR: 120000: 40000 


The partition name DRVPAR is the typical name of a 
conventional partition reserved for drivers. A driver may be 
loaded into any system-controlled partition. The base 
virtual address of the partition is always 120000 (8). That 
is, the loadable driver must be mapped through kernel APR5. 
The length of the partition, the second parameter should not 
exceed 8K words (40000 octal bytes). 


The double slash ends the option phase of the Task Builder. 


5.2.4 Loading the Driver 


After your driver is task built, you are ready to load the driver on 
your system. This procedure is used when you are incorporating your 
loadable driver with a loadable data base after system generation. 
Loading is done by using the privileged MCR command LOAD. Its form 
is: 


>LOAD xx: [/PAR=GEN] [/HIGH] 
> 
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The vaciable xx is the 2-character device mnemonic. Specifying a 
partition is optional. If a partition is not specified, the partition 
input =o the Task Builder is used. The keyword /HIGH puts the driver 
as higi as possible in the partition. The default condition is to put 
the driver as low as possible in the partition. 


LOAD performs many diagnostic checkS on your driver data base, 
relocazres many addresses within the data base, and loads the data base 
and the driver code into memory. Because the LOAD diagnostic checks 
are complicated and LOAD supports another, infrequently used option 
(/CTB), a description of LOAD is given in Section 5.4. LOAD error 
messages and meanings are listed in the RSX-11M/M-PLUS MCR Operations 
Manual. After the driver is loaded, the controller(s) and units are 
off-line and are not accessible. To allow access to the device, you 
must next place the controller(s) and unit(s) on-line. 


5.2.5 Making the Devices Accessible 


After your driver has been successfully loaded, you must make the 
controller(s) and units accessible. You use the CON task to place 
controller(s) and units on-line, to change vector and CSR assignments 
that you established in the driver data base, and to take units and 
controller(s) off-line. Unless the vector and CSR values in the 
driver data base are not correct for the running system, you can place 
the coitroller(s) and units on-line. You may change the vector and 
CSR assignments to match the hardware CSR and vector assignments only 
while the controller(s) and units are off-line. 


5.2.5.1 Setting Vector and CSR Assignments - If the values at_ the 
offsets S.VCT/K.VCT and S.CSR/K.CSR in the KRB(sS) of your driver data 
base are incorrect for the running system, you must issue the 
privileged SET command in CON to eStablish the correct values. 


NOTE 


Because CON causes the Executive to 
access a driver data base when it 
changes a vector or CSR assignment, you 
must load the driver before you issue 
the SET commands in CON. If a driver 
data base is resident, you do not need 
to load the driver to establish correct 
vector and CSR assignments. 


You must do this operation while the controller(s) and units are 
off-line. (LOAD enSures that, for a loadable data base, the 
controller(s) and unit(s) are off-line.) Typical commands to set a 
vector and CSR for a driver that supports a single controller are as 
follows: 


> SON 

CIN>SET xxA VEC=300 CSR=160040 
CIN>*Z 

> 


The command first establishes 300 as the vector for controller A of 
type <x. The Executive accesses the offset S.VCT/K.VCT in the driver 
data base and writes the specified value divided by 4. The command 
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secondly establishes the control and status register address as 160040 
for controller A of type xx. The Executive accesses the offset 
S.CSR/K.CSR in the driver data base and writes the specified value. 
You type the CTRL/Z combination to exit from CON. After you set the 
vector or CSR assignment, you can attempt to place the controller(s) 
and units on-line. 


5.2.5.2 Placing a Controller and Units(s) On-Line - If the vector and 
CSR assignments in your driver data base are correct for the running 
system, you can place the controller(s) and units on-line by issuing 
the privileged ONLINE command in CON. 


NOTE 


Because placing a controller or a unit 
on-line causes the Executive to call the 
driver, you must have loaded the driver 
before you issue the ONLINE command in 
CON. 


The following commands demonstrate a typical sequence to place a 
Single controller and two attached units on-line. 


>CON 
CON>ONLINE xxA 
CON>ONLINE xx0O: 
CON>ONLINE xxl: 
CON>*Z 

> 


The first command places controller A of type xx on-line. The 
Executive accesses the KRB of the controller to read the S.VCT/K.VCT 
offset and initializes the vector to point to the related interrupt 
control block. 


NOTE 


If the driver is resident within the 
Executive, the vector points directly to 
the driver. For a common interrupt 
controller, the vector points to the 
interrupt entry address in the Executive 
rather than to an ICB. 


The Executive then ensures that the address in S.CSR/K.CSR is valid 
(that is, some device responds at that address). Refer to Section 
5.2.5.3 for a discussion of CSR and vector assignment errors. Next, 
the Executive calls the driver at its controller status change entry 
point. Only after the driver indicates success does the Executive 
change the status bit in the SCB/KRB of the controller from off-line 
to on-line. 


The second and third commands place logical units 0O and 1 on-line. 
The Executive checks that the controller is on-line (that is, an 
access path exists to the unit). If the controller is not on-line, 
the Executive sets the UCB of the unit as marked for on-line. (The 
Executive automatically places on-line a unit that is in the marked 
for on-line state only when its controller is placed on-line.) If the 
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contro. ler is on-line, the Executive calls the driver at its unit 
Status change entry point. Only after the driver indicates success 
dces tlt.e Executive change the status bits in the UCB of the unit from 
off-lire to on-line. (The driver is not required to take any special 
action to indicate success. Refer to the discussion of status change 
entry points in Section 4.5.) 


After vou have issued the ONLINE commands, you can issue the DISPLAY 
commanc in CON as follows to verify that the devices are in the state 


that ycu want them to be in: 


>C ON 
CCN>DISPLAY FULL FOR xx 


(The display appears at the terminal.) 


CON>*Z 
> 


The command displays status of all controllers of type xx and of all 
units ~ettached to the controllers. 


5.2.5.2 CSR and Vector Assigment Errors - CSR and vector assignment 
errors are not always immediately detectable. When you issue the 
ONLINE command to CON to place a device on-line, CON verifies that 
some cevice responds at the CSR address that you established at the 
S.CSR/K.CSR offset in your driver data base. CON can encounter one of 
three possible cases: 


e Your device is at the established CSR address and it responds 
to the CON probe. This is the case you want. CON continues 


attempting to place your device on-line. 


e Your device is at some address in the I/O page other than the 
established CSR address, but some other device responds at the 
established CSR address. CON cannot distinguish your device 
from Some other device, and continues attempting to place your 
device on-line possibly resulting in a system hang or crash. 


e Your device is at some address in the I/O page other than the 
established CSR address, and no device responds at the 
established CSR address. In this case, CON reportS an error 
and does not place the device on-line. 


Therefore, if CON places your device on-line and the device 
subsequently does not respond, have a DIGITAL Field Service 
representative verify the CSR address jumpers and ensure that the CSR 
assignment in your driver data base matches the verified hardware CSR 
assignment. 


When the vector address developed from the value that you established 
at the offset S.VCT/K.VCT in the driver data base differs from the 
hardware vector assignment, several outcomes are possible. Should the 
established vector already be in use (that is, pointing at other than 
the nonsense interrupt entry address in the Executive), CON reports 
the condition and does not place the device on-line. If the vector is 
not in use, CON establishes it as the device vector and _ continues 
attempting to place the device on-line. This action does not 
guarantee that the software and hardware vector assignments match. 
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When CON does place a device on-line and the software and hardware 
vector assignments do not match, two results are possible: 


e Your driver will time out waiting for an interrupt. 
e The device will interrupt through an unused vector. 


If error logging is active on your system, a nonsense interrupt will 
be logged as an undefined interrupt error and the ERRSEQ count in the 
Executive is increased by 1. The RMDEMO task display, which includes 
the ERRSEQ count, will reflect the occurrence of nonsense interrupts 
by an increasing number in ERRSEQ. Consult an error log report and 
look for undefined interrupt errors. 


When (1) error logging is active, (2) nonsense interrupts do not 
occur, and (3) your driver times out, the interrupt could be going 
through some other driver vector. If the unexpected interrupt goes to 
a DIGITAL-supplied driver, one of two outcomes is possible. 


e The interrupt will simply be dismissed. (Common interrupt 
routines dismiss unexpected interrupts and some drivers keep 
track of when they expect interrupts and dismiss unexpected 
ones.) 


e The driver will react in an unpredictable fashion (Such as 
attempting to terminate the last I/O packet again) causing a 
system crash. 


Thus, error logging and the ERRSEQ count in the RMDEMO display help 
indicate improper vector assignments. 


5.3 USER-SUPPLIED DRIVER SYSTEM GENERATION DIALOGUE SUMMARY 


If you are building either a loadable driver with a resident data base 
or a resident driver, you must perform a system generation to 
incorporate your driver into the system. This section summarizes’ the 
system generation dialogue only as it relates to user-supplied driver 
support and related features. For more information on the- system 
generation procedure itself, refer to the RSX-11M-PLUS System 
Generation and Installation Guide. 


NOTE 


If you are building a loadable driver 
with a loadable data base, you need not 
perform a system generation to 
incorporate your driver. However, you 
can still build your driver during 
system generation. Section Dialed 
describes the complete procedures’ to 
build a loadable driver with a loadable 
data base any time after you build the 
Executive under which the driver will 
run. 


5.3.1 Choosing Executive Options 


The system features are determined during the "Choosing Executive 
Options" section. You have to specify answers related to including a 
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user-Sipplied driver in your system. A question in the following form 
appears: 


> Do you want the Full-functionality Executive? [Y/N D:Y]: 


If you choose the Full-functionality Executive, your driver must be 
loadable with either a loadable or resident data base. If you want to 
incorporate a user-supplied resident driver, you must omit the 
Full-faunctionality Executive and omit Executive data space support. 
All DIGITAL-~supplied drivers should be loadable with a loadable or 
resident data base. 


If you do not choose the Full-functionality Executive, the system 
generation procedure asks the two following questions: 


> Do you want Executive data space support? [Y/N D:N]: 


If you have a loadable driver with either a loadable or resident data 
base, you should answer Yes to this question. If you have a resident 
driver, you muSt answer No to this question. 


> What is the ICB pool size (in words)? [D R:16.-1024. D:128.]: 


On systems with Executive data space, the ICB pool must be large 
enough for all the drivers loaded into the virgin system image. One 
ICB (8 words) is needed for every 16(10) controllers of the same type. 
If the device controlled by your driver has a large number of 
controllers, you should ensure that there is enough ICB pool space. 


Whether you choose the Full-functionality Executive or not, another 
question in the following form asks about XDT support: 


> Do you want to include XDT? [Y/N D:N]: 


You should answer Yes to this question. XDT (described in Chapter 6) 
is helpful in debugging system problems which incorporating a faulty 
driver may engender. 


After this question, there are no more questions in this’ section 
concerning user-supplied driver support or related features. 


5.3.2 Choosing Peripheral Configuration 


In the Peripheral Configuration section of the system generation 
procedure, you must answer questions about your driver and its data 
base configuration. A question in the following form asks you _ to 
supply your device mnemonics: 


> Enter device mnemonics for user-supplied drivers [S]: 


You must enter the 2-character device mnemonic for your driver. This 
should be the same mnemonic used in the driver and data base source 


file names. 


If you did not select Executive data space support, a question in the 
following form appears: 


> Do you want the xx: driver to be loadable? [Y/N D:N]: 


Answer Yes to this question if you want a loadable driver. Answer No 
if you want your driver to be resident. 
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If your driver is loadable, the next question in the system generation 
procedure asks you about your data base: 


> Do you want the xx: driver's data base to be loadable? [Y/N D:N]: 


Answer Yes to this question if you want a loadable data base. Answer 
No if you want your data base to be resident. 


The system generation procedure always asks you to specify the highest 
interrupt vector address: 


> What is the highest interrupt vector address? [0 R:n-774 D:n]: 


The system generation procedure calculates and displays the highest 
interrupt vector address needed for the DIGITAL-supplied devices. If 
the vector address for your device is higher than this, enter’ the 
highest vector address used by your device. 


This ends the system generation portion of incorporating a 
user-Supplied driver. If you are generating a new system, the system 
generation procedure includes your driver in the Executive if it is 
resident, or loads your driver into the system image if it is 
loadable. After the newly built system is running, you must make the 
devices that your driver supports accessible, as directed in Section 
Sets Os 


If you are adding your driver after system generation, you must load 
your driver and make the devices that it supports accessible, as 
described in Sections 5.2.4 and 5.2.5. 


5.4 LOAD PROCESSING 


The Executive LOAD routines extensively check the driver data hbase; 
LOAD provides the /CTB switch to handle multidriver controllers. The 
following subsections describe the two aspects of LOAD. 


5.4.1 LOAD Operations and Diagnostic Checks 


Two modules (LDVLDB and LDVFIN) in LOAD, load a driver into memory: 
one conditionally checks the validity of and loads the data base; and 
the other finishes the operation by loading the driver. If there is 
no reSident data base, the data base is loaded into the system pool. 
The LOAD routines relocate and validate many of the pointers within 
the data base and, in the process, validate other data in the 
structures. (If the data base is resident, no’ validity checks on the 
driver data base are performed.) The driver itself is then loaded into 
its partition, and the interrupt control blocks are created. 


To read the data base from the xxDRV.TSK file into the system pool, 
the global labels $xxDAT and $xxEND, defining the start and end of the 


data base, are needed. 


To check the data base, the LOAD routines must know the starting 
address of the DCB. If the global label $xxDCB is not defined (that 
is, not in the symbol table file), the start of the DCB is assumed to 
be the first word of the data base. Many unusual error conditions 
result when LOAD assumes that the DCB is at the start of the data base 
and the DCB is elsewhere in the data base and not labelled properly. 
Thus, to avoid this type of problem, you should always define the 
Start of the DCB with the global label $xxDCB. 
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Each CTB is checked and relocated. The following offsets are both 
checked and relocated: 


L.LNK 


L,.DCB 


L.KRB 


The link to the next CTB must be even. If it is 
not zero, it must point within the data base, and 
the CTB to which it points must lie within the 
data base. (Because it is highly unusual to have 
two controller types in one driver data base, this 
value is uSually zero.) 


The address of the related DCB must be even, point 
within the data base, and the DCB to which it 
points must lie within the data base. LE -G.DEB 
points to a common interrupt table, the common 
interrupt entry point address in the table must be 
even and lie within the Executive. The DCB 
address(es) in the table must be even, and_ the 
DCB(s) to which each address points must lie 
within the data base. 


Each pointer in the table of KRB addresses must be 
even and must point within the data base, and the 
KRB to which each cell points must lie within the 
data base. 


The fo .lowing offsets in the CTB are checked: 


L.NAM 


L.NUM 


The controller name cannot duplicate other L.NAM 
entries in the resident or loadable data base. 


The number of controllers must be less than 17 
(decimal). 


Each KRB is checked and relocated. The following offsets in the KRB 
are both checked and relocated: 


K. OWN 


K. OFF 


K.CRQ 
K.CRQ+2 


The pointer to the owner UCB muSt be even. and 
Point within the data base, or be zero. If it is 
nonzero, the pointer is relocated. 


The start of the table of UCB addresses’ produced 
from K.OFF must be even and must point within the 
data base. The entries themselves must be even, 
point within the data base, and the UCB to which 
each cell points must lie within the data base. 


The listhead for the controller request queue. 
It is initialized to an empty list with the first 
word zero, and the second word pointing to the 
first, relocated. 


The following offset in the KRB is checked: 


K.URM 


In a multiprocessor system, the UNIBUS run- mask 
for the controller must have exactly one bit set 
and that bit must correspond to an existing UNIBUS 
run (either primary or secondary). 


LOAD puts each controller in the off-line state by setting the KS.OFL 
bit in the K.STS byte. Therefore, all controllers are off-line until 
you use CON to place each one on-line. 
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Each DCB is checked and relocated. The following offsets are both 
checked and relocated: 


D.LNK The link to the next DCB must be even. If it is 
nonzero, it must point within the data base, and 
the DCB to which it points must lie within the 


data base. 


D.UCB The link to the first UCB must be even and must 
point within the data base, and the UCB to which 
it points must lie within the data base. 


The following offsets in the DCB are checked: 


D.NAM The device name must be the same as that which you 
specified in the LOAD command line. 


D.UCBL The length of the UCB must be even and nonzero. 


D.UNIT The highest unit number (increased by 1) used with 
D.UCBL forms the last address of all UCBs. This 


address must lie within the data base. 


The pointer to the driver dispatch table (D.DSP) is set to zero to 
show that the driver is not loaded. 


Each UCB is checked and relocated. The following offsets are both 
checked and relocated: 


U.DCB The pointer to the DCB must point to the DCB that 
points to this UCB. 


U.SCB The pointer to the SCB must be even, must point 
within the data base, and the SCB to which it 
points must lie within the data base. 


U.RED The unit redirect pointer must be nonzero and even 
if it is an Executive address. If it is not an 
Executive address, it must be nonzero, even, and 
point within the data base. 


LOAD places each unit in the off-line state by setting the US.OFL bit 
in the U.ST2 byte. Therefore, all units are off-line until you use 
CON to place each one on-line. 


Each SCB is checked and relocated. The following offsets are both 
checked and relocated: 


S.KRB The pointer to the KRB must be even, must point 
within the data base, and the KRB to which it 
points must lie within the data base. If S.KRB is 
nonzero, there must be a CTB in the loadable data 
base. 


S.KTB If the table of KRB addresses is present, each 
entry must point within the data base. (LOAD 
preserves bit zero in each entry.) Each entry in 
the table must also have a matching entry in the 
table of KRB addresses of a CTB in the loadable 
data base. 
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The following offsets in each SCB are initialized as described: 


¢.LHD The head of the I/O queue is set to zero and _ the 
pointer to the end of the queue (S.LHD+2) is set 
to point at S.LHD. 


€. PKT The pointer to the current I/O packet is set to l. 
These last checks end the loading and validating of the data base. 


After the data base is loaded and validated and no error is found, the 
driver itself is loaded into memory. In loading the driver, the 
driver dispatch table is validated, each interrupt entry in the driver 
dispatch table is inspected, and the vector(s) are checked. If a 
vector address is higher than the highest vector address allowed on 
the system (as specified at system generation) or does not point to a 
nonsense interrupt entry point, LOAD prints a warning message. You 
can use CON to set the correct vector address before you place the 
controller on-line. Interrupt control blocks are created and _ linked 
into the list starting at L.ICB in the CTB. 


The format of the DDT must be consistent with that described in 
Seceren. 4. 54k. If the device that the data base describes does not 
have any physical controllers (that is, the value at offset 
S.VCT/K.VCT equals zero), the DDT is not checked. If S.VCT/K.VCT is 
nonzero, the device has at least one interrupt vector and therefore at 
least one interrupt entry point. The DDT is then checked. The two 
global labels $xxTBL and $xxTBE must define the start and end of the 
DDT. The generic controller name(s) must be nonzero and the interrupt 
entry values must be valid. Interrupt entry point 0 must be nonzero, 
even, and lie in the range 117777 and 140000. If the format of DDT is 
inconsistent, LOAD prints an error message, restores the system device 
tables, and exits. 


When the driver is loaded, all links are eStablished. The DCB of the 
loadakle data base is put in the list of DCBs just in front of the DCB 
for the first pseudo device. The CTB(s) are linked to the end of the 
CTB list. The DDT address D.DSP, the driver PCB address D.PCB, and 
the driver mapping S.KS5 (the block number of the first word of the 
driver) in the fork block are initialized. The address of the start 
of the KRB table in the CTB, denoted in the driver data base by the 
global label $xxCTB, is loaded into the DDT. 


5.4.2 Use of /CTB in LOAD 


Some controllers such as the RH70 can support more than one _ device 
type. The CTB for such a controller differs in two ways from the 
Standard CTB. First, the table of KRB addresses at the end of the CTB 
contains pointers to KRBs of controllers for different device types. 
Second, instead of a pointer to one DCB in the CTB, there is a pointer 
to a table of DCB addresses because each different device must have a 
separate DCB to describe each separate device type. Morever, more 
than one driver supports the different types of devices capable of 
being attached to the controller. 


The data base for such a controller must necessarily be split. 
Because only one CTB is needed to describe the type of controller, 
only one driver that supports a device on that controller type can 
define that CTB. The remaining drivers cannot define a CTB but must 
reference the CTB defined for the first driver. Because all drivers 
and their data bases can be loadable, the remaining drivers and the 
syntax in the LOAD command must indicate to the LOAD routines’ which 
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resident CTB to use. (Of course, the driver data base that defines 
the CTB of the multidriver controller must’ be loaded or already 
resident before the other drivers can be loaded.) 


The driver data base that defines the CTB for a multidriver controller 
allows for structures to define the data base of drivers that are not 
resident. In particular, for each device controller there must be a 
Slot in the CTB table of KRB addresses to hold the pointer to the KRB. 
(A KRB must be defined to describe each occurrence of a controller.) A 
zero is in the pointer for a device whose data base (and therefore, 
whose KRB) is not resident. Moreover, the table of DCB addresses in 
the common interrupt table must have sufficient slots to point to the 
DCBs of all device types that the controller supports. A zero in the 
DCB table indicates no DCB exists (that is, the data base for a device 
type is not resident). 


To load the data base of a device attached to the multidriver 
controller, the LOAD routines must know the controller name, the 
location of the device on the MASSBUS controller and the KRB(s) of the 
device(s) whose driver is to be loaded. The /CTB syntax in the LOAD 
command supplies the first two pieces of information. For example: 


>LOA DR:/CTB=RHB,C 
> 


The letters RH are the name in the CTB already resident in the system. 
LOAD routines search the system list of CTBs to locate the correct 
one. The letters B and C are the slots in the table of KRB' addresses 
that will be used to link the resident CTB with the KRB in the data 
base being loaded. 


The name of the device DR reflects the name in the DCB that is being 
loaded. An empty slot in the table of DCB addresses in the resident 
data base will be made to point to this DCB. 


The LOAD routines need to find the correct KRB in the data base being 
loaded. A global label of the form $cca (where cc is the controller 
name and ais the slot, or controller number) must define the start of 
the KRB(s) being loaded. Thus, the loadable data base for the example 
above must contain the labels $RHB and S$RHC, which are the KRB- names. 
The address(es) of the label(s) is loaded into the appropriate slot in 
the CTB table of KRB addresses. 


In summary, then, the /CTB syntax on the LOAD command combined with 
the global label(s) allows the LOAD routines to link a driver data 
base being loaded with a currently resident driver data base. The 
KRB(s) being loaded are incorporated in the resident data base and the 
DCB being loaded is connected to the common interrupt table. 


CHAPTER 6 


DEBUGGING A USER-SUPPLIED DRIVER 


Adding a user-supplied driver carries with it the risk of introducing 
obscure bugs into an RSX-11M-PLUS system. Because the driver runs as 
part of the Executive, special debugging tools are both desirable and 
necessary. RSX-11M-PLUS provides such aids, which can be incorporated 
into your system during system generation: 


1. Crash dump analysis support routine (CDA) 
2. Executive debugging tool (XDT) 


You need not select any of this software during system generation. 
If, however, you do require the facilities they offer, you can select 
them for incorporation in your’ system. The following sections 
describe the features and use of each debugging aid. 


6.1 CRASH DUMP ANALYSIS SUPPORT ROUTINE 


The crash dump analysis (CDA) support routine prints the _ following 
message on a notification device specified at system generation: 


CRASH - CONT WITH SCRATCH MEDIA ON device mnemonic 


You can then ensure that the secondary crash dump device is ready and 
depress the CONT switch on the operator's console. The Executive 
Crash Dump routine will dump memory to the crash dump device and halt 
the processor upon completion. 


The procedure for subsequently invoking CDA, which reads and _ formats 
the memory dump, is documented in the RSX-11M/M-PLUS Crash Dump 
Analyzer Reference Manual. 


6.2 THE EXECUTIVE DEBUGGING TOOL 


An interactive debugging tool aids in debugging Executive modules, I/0 
drivers, and interrupt service routines. This debugging aid, called 
XDT, is a version of RSX-11 ODT. Including XDT in a_ system with 
Executive data space support does not reduce the size of pool space 
that the system can have. XDT occupies physical address space _ but 
does not take up any Executive virtual data address space. xXDT also 
does not interfere with user-level RSX-1l1l ODT, which can be used with 
any number of tasks while you are debugging your driver with XDT. 


You can include XDT in a system during the "Choosing Executive 
Options" section of system generation when the following question is 
asked: 


Do You Want To Include XDT? [Y/N D:N] 
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If you answer Y, XDT is linked into the Executive image when you build 
the Executive. 


6.2.1 XDT Commands 
XDT commands are generally compatible with RSX~-11 ODT commands, which 
are described in the IAS/RSX-11 ODT Reference Manual. That manual, 


together with the discussion in Section 6.2 in this manual, can be 
used aS a guide to XDT operation on RSX-11M-PLUS. 


XDT does not contain the following commands available in ODT: 


No SM - (Mask) register 


No SX (Entry Flag) registers 
No $V - (SST vector) registers 
No $D - (I/O LUN) registers 

No SE - (SST data) registers 


No SW - (Directive status word) SDSW word 


No E - (Effective Address Search) command 
No F - (Fill Memory) command 

No N - (Not word search) command 

No V - (ReStore SST vectors) command 

No W - (Memory word search) command 


In addi‘:ion, the X (Exit) ODT command has been changed for XDT. The X 
command causes a jump to the crash dump routine. 


Except ‘or the omitted features and the change in the X command, xXDT 
is  comnand-compatible with RSX-11 ODT; consequently, the IAS/RSX-11 
ODT Reference Manual can be used aS a guide to XDT operation. 


XDT includes both Instruction space and Data space address 
referencing. The following commands control the current address 


referencing: 
I sets address references to Instruction space 
D sets address references to Data space 


When XD1 starts up, the default condition is that address references 
are to Data space. 


6.2.2 %DT Start Up 

When yot bootstrap a system that includes XDT, the normal system 
Startup transfers control to XDT, which identifies itself at the 
system console terminal with the following message: 


XDT: <system name and version> 
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If no errors were encountered, the identification message is followed 
by the prompt: 
XDT> 


The following are the register conditions when XDT starts: 


RO = CSR address of the bootstrap device 

Rl = LBN of the system image 

R2 = LBN of the system image 

R3 = physical unit number of the load device 

R4 = ASCII name of the load device 

R5 = total number of blocks read from the system image 


XDT runs entirely at priority level 7. 


You can set breakpoints at this time, and then give a G command, 
passing control to the Executive initialization module INITL. 
Whenever control reaches a breakpoint, a printout similar to that of 
RSX-11 ODT occurs. 


If INITL encounters an error condition, it prints an error message 
preceded by a prefix telling whether the condition is a warning or 
fatal. If the condition is a warning, XDT has control. You can set 
breakpoints to establish control or type the P command to proceed. If 
the condition is fatal, the processor halts. You must correct’ the 
condition before you can rebootstrap your system. 


6.2.3 xXDT Restrictions 


On some types of systems, the following restrictions exist on the use 
of XDT when it is first entered: 


1. All systems 


Some data structures are not yet initialized. The secondary 
pool is not set up and the console terminal and_ the 
bootstrapped device are not on-line. 


2. Systems with Kernel data space support 


Data space mapping is not yet set up. Certain Executive 
locations that the Task Builder could not resolve are not 
initialized. (The RH common interrupt table address (S$RHTBX) 
does not contain the RH common interrupt routine address 
(SRHALT) .) 


To proceed when you encounter such restrictions on your system, at the 
initial XDT prompt you should first set a breakpoint near the end of 
the INITL module (after the routine that sets up the data structures). 
Then, after you proceed and XDT encounters the breakpoint near the end 
of INITL, use XDT to examine locations in the Executive and to. set 
more Executive breakpoints. 


On a multiprocessor system, you should be aware of the _ following 
conditions: 


1. When you initially place a processor on-line, XDT does not 
prompt from that processor unless you have set the 
processor's bit in the $XDTPR word. 


2. XDT does not handle multiprocessor-specific conditions. You 
cannot set processor-specific breakpoints nor can you easily 
examine other processors' low memory context. 
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3. Under certain circumstances (such as when Data space is not yet 
set up), setting a breakpoint in shared Instruction space may 


eventually cause a trap on a processor other than the = one 


which you set the breakpoint. Consequently, because the 
processor encountering the breakpoint does not have that 
breakpoint in its XDT tables, XDT generates a breakpoint error 


message (BE:) rather than a breakpoint message. 


4. All processors are locked out of the Executive while XDT 
being executed by one of the other processors. 


6.2.4 XDT General Operation 


A forced entry to XDT can be executed at any time from a _ privileged 
terminel by means of the MCR Breakpoint (BRK) command. Thus, if your 
system has no XDT restrictions as described in Section 6.2.3, the 
normal procedure is to type G when the system is bootstrapped without 
settinc any breakpoints. When it becomes necessary to use XDT, the 
MCR Breakpoint command is executed, cauSing a forced breakpoint. xXDT 
then prints on the console terminal: 


BE :XXXXXX 
This message is followed by the prompt: 
XI T> 


You car then set breakpoints and issue other XDT commands. Continue 
system operation by typing the Proceed (P) command to XDT. 


All XD1 command I/O goes to and from the console terminal, and the 
List Memory (L) command can list on either the console terminal or the 
line printer. 


6.2.5 XDT and Debugging a User-Supplied Driver 


Using x¥DT to debug a loadable driver has special pitfalls. One 
problen that can arise is a T-bit error: 


TE sxXxxXXXX 
XI T> 


This error results when control reaches a breakpoint that you have 
set, wvsSing XDT, in a loaded driver. The T-bit error, rather than the 
expected BE: error, occurs unless register APR5 is mapped to the 
driver at the time XDT sets the breakpoint. 


To avoid this T-bit error, assemble the driver with an embedded  BPT 
instruction, or use either the ZAP utility or the MCR OPEN function to 
set the breakpoint by replacing a word of code with the BPT 
instruction. You can use the OPEN command in the following way to 
access the driver: 


>CPE nnnn/DRV=xx: 


where nnnn matches the address in the driver map listing and xx is the 
device mnemonic. (Write down the instruction that you replace with 
the BPT instruction.) 
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When control reaches a breakpoint set in the driver, XDT prints: 


BE:xxxxXx 
XDT> 


Recover as follows: 


1. Using XDT, replace the BPT instruction with the desired 
instruction. 


2. Decrement the PC by subtracting 2 from the contents of 
register R7. 


3. Then proceed by using the P or S commands. 


NOTE 


You should not set breakpoints in more 
than one module that maps into’ the 
Executive through APR 5 or APR 6. In 
particular, do not set breakpoints in 
more than one loadable driver at a time 
or XDT will overwrite words of main 
memory when it attempts to restore what 
it considers to be the contents of 
breakpoints. 


6.3 FAULT ISOLATION 
Four causes can be identified when the system faults: 


l. A user-state task has faulted in such a way that it causes 
the system to fault. 


2. The user-Supplied driver has faulted in such a way that it 
causes the system to fault. 


3. The system software itself has faulted. 

4. The host hardware has faulted. 
When the system faults, you must first decide which of these four 
causes is responsible. This section presents some procedures that can 


help you isolate the source of the fault. Correcting the fault itself 
is your responsibility. 


6.3.1 Immediate Servicing 


Faults manifest themselves in four ways (they are listed here in order 
of increasing difficulty of isolation): 


l. If XDT is included, an unintended trap to XDT occurs. 


2. The system displays text indicating a crash has occurred and 
halts. 


3. The system halts but displays nothing. 


4. The system is in an unintended loop. 
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The following discussions assume the existence of a system built with 
at least one debugging aid. 


The immediate aim, regardless of the fault manifestation, is to get to 
the point where you can obtain pertinent fault isolation data. 


6.3.1.1 The System Traps to XDT - The trap may or may not be intended 
(for example, a previously set breakpoint). If it is not intended, 
type the X command, causing XDT to exit to location 40(8), from which 
the CIA support routine will be invoked. If, however, you have some 
idea of the source of the problem (for example, a recent coding 
change), then you may use XDT to examine pertinent data structures and 
code. 


6.3.1.2 The System Reports a Crash - If the text displayed on the 
console terminal consists of output from the CDA support routine, 
follow the procedure for obtaining and formatting a memory dump as 


6.3.1.2 The System Halts but Displays No Information - Before taking 
any action, preserve the current PS and PC and the pertinent device 
registers (that is, examine and record the information these registers 
contain). The procedure depends on the particular PDP-1l processor. 
Consult the appropriate PDP-11l processor handbook for details. 


After preserving the PS and PC, invoke your resident debugging aid: 
enter 40(8) in the switch register, press LOAD ADDR, and then press 
START. The contents of 40(8) cause the invocation of the CDA support 
routine. 


6.3.1.4 The System Is in an Unintended Loop - Proceed as follows: 


l. Halt the processor. 


2. Record the PC, the PS, and any pertinent device registers, as 
in Section 6.3.1.3. 


You may then want to step through a number of instructions in an 
attempt to locate the loop. For this attempt to be meaningful you 
must first disable the system clock. Proceed as follows: 


1. Examine the contents of word 777546 (if your system has a 
line-frequency clock) or word 772540 (if your system has a 


Programmable clock). 


2. Clear bit 6 in this word and redeposit the word. 


NOTE 


Until you reenable the clock, some 
system operations do not work because 
they are waiting for time. You can type 
and the system echoes typed characters. 
You can input MCR commands. 
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After trying to locate the loop and reenabling the clock, transfer to 
location 40(8) as in Section 6.3.1.3. 


6.3.2 Pertinent Fault Isolation Data 
Before you attempt to locate the fault, you should dump system common 
(SYSCM). SYSCM contains a number of critical pointers and listheads. 
CDA always dumps the SYSCM area. In addition, you should dump the 
dynamic storage region (system pool and, if it exists, the ICB pool) 
and the device tables. The device tables are in the module SYSTB. 
At this point, you have the following data: 

e PS 

@e PC 

e The stack 

e RO through R6 

e Pertinent device registers 

e The dynamic storage region 

e The device tables 


e System common 


These data represent a minimal requirement for effectively tracing the 
fault. 


6.4 TRACING FAULTS 


Three pointers in SYSCM are critical in fault tracing. These pointers 
are described below: 


SSTKDP - Stack Depth Indicator 


This data item indicates which stack was being used at the time 
of the crash. SSTKDP plays an important role in determining the 
origin of a fault. The following values apply: 


+1 -- User (task-state) stack or a privileged task at user 
state 
0 or less -- System stack 


If the stack depth is +l, then the user has crashed the system. 
STKTCB - Pointer to the Current Task Control Block (TCB) 

This is the TCB of the user-level task in control of the CPU. 
SHEADR - Pointer to the Current Task Header (Pool-Resident) 
The task header and its associated pointers are described below. 


The location of the task header and the contents of its associated 
pointers vary according to whether the task has an external header. A 
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task with an external header has its header attached in a physically 
contiguous and numerically lower location in memory. A task with a 
nonexternal header has its header located in Executive pool space. 
Therefore, a header in Executive pool is a pool-resident header, and a 
header adjacent to the task is a non-pool-resident header. 


Figure 6-1 shows the interaction of header pointers for both 
pool-r2sident and non-pool-resident headers. For a pool-resident task 
header, SHEADR, SSAHPT, and S$SAVSP all point to the first word of the 
task ieader. This word also contains the user task's stack pointer 
(SP) from the last time it was saved. Figure 6-2 shows a brief 
descrintion of the task header. The task header is fully described in 
the RSX-11M/M-PLUS Task Builder Manual. 


POOL-RESIDENT TASK HEADER (Non-external) 


Virtual Header Addr. 
$S$HEADR 


Saved Stack Addr. 
$SAVSP Header 


Current Task 


Virtual Header Addr. 
$SAHPT Saved Stack Pointer 
THDLN O 
$SAHDB_ undefined value 


NON-POOL-RESIDENT TASK HEADER (External) 


: Task 


$SAHPT 140000 
$HEADR 


’ Current Task 
Header 


Executive 
Data Area 

SSAVSP 1-word block THDLN 0 
Executive 


Figure 6-l: Interaction of Task Header Pointers 


7K.9OT-BS 


The header (as pointed to by SHEADR) also contains the last-saved 
register set, just before the header guard word (the last word in the 
header -- pointed to by H.GARD). 


The four pointers asSociated with the header are: 


e SHEADR 
e SSAVSP 
e SSAHPT 
e SSAHDB 
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Figure 6-2: Task Header 


The pointers associated with a pool-resident header are described 


next: 


SHEADR - 


SSAVSP 


SSAHPT 


SSAHDB 


Points to the current task header. 


The S$HEADR word points to the pool-resident task header of 
the task currently running. The value in $HEADR is a kernel 
virtual address in primary pool. 


Points to the first word of the current task header, which 
contains the saved stack pointer. 


Points to the current task header in pool. SSAHPT contains 
the virtual address of the header. SSAHPT and S$HEADR contain 
the same virtual address for a pool-resident header. 


Contains an unknown value. 


The pointers associated with a non-pool-resident header are described 


next: 
SHEADR - 
SSAVSP - 


SSAHPT - 


Points to the pointer for the saved stack pointer, SSAVSP. 
Points to a 4-word block in the Executive data area. 
Contains the octal value of 140000 that is to be used with 


SSAHDB to resolve the address of the task's header. S$SAHPT 
always contains 140000 in this case. 
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SSAHDB - Contains the value in KISAR6, which is a 32-word block-offset 
to be used with the value in SSAHPT to resolve the address of 
the task's header. 


6.4.1 Tracing Faults Using the Executive Stack and Register Dump 


To trace a fault after a display of the Executive stack and _ register 
contents, first examine the system stack pointer. Usually an 
Executive failure is the result of an SST-type trap within the 
Executive. If an SST does occur within the Executive, then the origin 
of the call on the crash-reporting routine is in the SST service 
module. (The crash call is initiated by issuing an IOT at a stack 
depth of zero or less.) 


A call to crash also occurs in the Directive Dispatcher when an EMT is 
issued at a stack depth of zero or less, or a trap instruction is 
executed at a stack depth of less than zero. The stack structure in 
the case of an internal SST fault is shown in Figure 6-3. 


— 
oe 


Figure 6-3: Stack Structure: Internal SST Fault 


<——___________—- sp 
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The fault codes are: 


0 ;ODD ADDRESS AND TRAPS TO 4 
2 ;MEMORY PROTECT VIOLATION 
4 ;BREAK POINT OR TRACE TRAP 
6 ;IOT INSTRUCTION 
10 ; ILLEGAL OR RESERVED INSTRUCTION 
LZ 7;NON RSX EMT INSTRUCTION 
14 ;TRAP INSTRUCTION 
16 711/40 FLOATING POINT EXCEPTION 
20 SST ABORT-BAD STACK 
2 ;AST ABORT-BAD STACK 
24 ;ABORT VIA DIRECTIVE 
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26 ;TASK LOAD READ FAILURE 

30 ;TASK CHECKPOINT READ FAILURE 
32 ;TASK EXIT WITH OUTSTANDING I/0 
34 ;TASK MEMORY PARITY ERROR 


The PC points to the instruction following the one that caused the SST 
failure. The number of bytes is the number normally transferred to 
the user stack when the particular type of SST occurs. If the number 
is 4, then a non-normal SST fault occurred, and only the PS and PC are 
transferred. There are no SST parameters. 


If the failure is detected in S$DRDSP, the stack is the same as that 
shown in Figure 6-3, except that the number of bytes, the SST fault 
code (the fault codes are listed above), and the SST parameters are 
not present. 


One SST-type failure, stack underflow, does not result in the stack 
Structure of Figure 6-3. To determine where the crash occurred, first 
establish the stack structure; this can be deduced by the value of 
the SP and the contents of the top word on the stack. If the stack 
structure is that of Figure 6-3, then the failure occurred in SDRDSP, 
or waS anormal SST crash. If the stack structure is that of Figure 
6-4, then an abnormal SST crash has occurred. 


<——___—_ P 
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Figure 6-4: Stack Structure: Abnormal SST Fault 


Abnormal SST failures occur when it is not possible to push 
information on the stack without forcing another SST fault. When this 
situation occurs, a direct jump to the crash-reporting routine is made 
rather than an IOT crash. The PS and PC on the stack are those of the 
actual crash, and the address printed out by the crash-reporting 
routine is the address of the fault rather than the address of the IOT 
that crashes the system. Note that the crash-reporting routine 
removes the PC and PS of the IOT instruction from the stack, which in 
this case is incorrect. Thus, the SP appears to be four bytes greater 
than it really is (as in Figure 6-4). 


You now have all the information needed to isolate the cause of the 
failure. From this point on, rely on personal experience and a 
knowledge of the interaction between the driver and the services 
provided by the Executive. 


6.4.2 Tracing Faults When the Processor Halts Without Display 


To trace a fault when the processor halts but displays no information, 
first examine $STKDP, S$TKTCB, SHEADR, SSAVSP, SSAHPT and SSAHDB. The 
difficulty in tracing failures in this case is that the system stack 
is not directly associated with the cause of a failure. 


By examining $STKDP, you can determine the system state at the time of 
failure. If it was in user state, the next step is to examine the 
user's stack. The examination focuseS on scanning the stack for 
addresses that may be subroutine links that can ultimately lead to a 
thread of events isolating the fault. This is essentially the aim of 
looking at the system stack if S$STKDP is zero or less. ; 
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Frequertly, a fault can occur that causes the SP to point to Top of 
Stack (TOS)+4. This fault results from issuing an RTI when the top 
two items on the stack are data. The result is a wild branch and 
then, most probably, a halt. Figure 6-5 shows a case in which two 
data items are on the stack when the program executes an RTI. TOS 
points to a word containing 40100. Suppose that location 40100 
contairs a halt. This indicates that the original SP was four bytes 
below the final SP, and fault tracing should begin from the 
original SP. 


40100 <—___-__________- sp 
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Figure 6-5: Stack Structure: Data Items on Stack 


This type of fault also occurs when an RTS instruction is executed 
with an inconsistent stack. However, in that case, SP points to 
TOS+2. 


A scan of the contents of the general registers may give some hint as 
to the neighborhood in which a fault (or the sequence of events 
leading up to the fault) occurred. 


If the fault occurred in a new driver, a frequent source of clues is 
the buffer address and count words in the UCB (U.BUF, U.BUF+2, U.CNT), 
as are the activity flags (US.BSY and S.STS). Other locations in both 
the UCB and SCB may also provide information that may help locate the 
Source of the fault. 


6.4.3 Tracing Faults After an Unintended Loop 


To trace a fault when an unintended loop has occurred, first halt the 
processor. 


After you halt the processor, the same state exists as was discussed 
in Section 6.4.2. Follow the same tracing procedure described there. 
A specific suggestion is to check for a stack overflow loop. Patterns 
of data successively duplicated on the stack indicate a stack looping 
failure. 


6.4.4 Additional Hints for Tracing Faults 


Another item to check is the current (or last) I/O Packet, the address 
of whith is found in S.PKT of the SCB. The packet function (I.FCN) 
defines the last activity performed on the unit. 


If trouxdle occurred in terminating an I/O request, a scan of the 
system dynamic memory region may provide some insight. This region 
Starts at the address contained in SCRAVL, a cell in SYSCM. Because 
all I/) packets are built in system dynamic memory, their memory is 
returned to the dynamic memory region when they are _ successfully 
terminazed. Following the link pointers in this region may reveal 
whether I/O completion proceeded to that point. In systems with QIO 
optimization, $PKAVL (SYSCM) points to a list of I/O packet-sized 
blocks of dynamic memory that are not linked into the SCRAVL chain. 
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A frequent error for an interrupt-driven device is to terminate an I/0 
Packet twice when the device is not properly disabled on I/0 
completion and an unexpected interrupt occurs. This action ultimately 
produces a double deallocation of the same packet of dynamic memory. 
Double deallocation of a dynamic buffer causes a loop in the module 
SDEACB on the next deallocation (of a block of higher address) after 
the second deallocation of the same block. At that time, R2 and R3 
both contain the address of the I/O Packet memory that has been doubly 
deallocated. If XDT has been included in the system, the deallocation 
routine checks for bad deallocation and crashes the system if it 
occurs. 


6.5 REBUILDING AND REINCORPORATING A LOADABLE DRIVER 


After correcting and assembling the driver source and updating the 
Executive object library, simply unload the old version, using the MCR 
command UNLOAD, task build the new one, and load it using the LOAD 
command. The commands for the assembler, Librarian, and Task Builder 
are shown in Section 5.2. 


Once loaded, the data base is not removed by the UNLOAD command. If 
the data base is in error and cannot be patched, correct its source, 
reassemble it, update the Executive object library RSX11M.OLB_= and 
build the new driver task. Then bootstrap the system before loading 
the driver task image containing the corrected data base. 


CHAPTER 7 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


BecauSe a driver is mapped within the Executive address space, it can 
call Executive routines on the same basis as that of any other module 
in the Executive. The driver must observe the protocol and 
conventions established on the system. The following sections 
Summarize the conventions, describe the address double word, tell what 
Special processing is required for NPR devices attached to a PDP-1l 
processor with extended memory support (22-bit addressing), and 
Summarize some of the typical Executive services available. 


7.1 SYSTEM-STATE REGISTER CONVENTIONS 


In system state, R5 and R4 are, by convention, nonvolatile registers. 
This means that an internally called routine is required to save and 
restore these two registers if the routine destroys their contents. 
R3, R2, Rl, and RO are volatile registers and may be used by a called 
routine without save and restore responsibilities. 


When a driver is entered directly from an interrupt, it is operating 
at interrupt level, not at system state. At interrupt level, any 
register the driver uses must be saved and restored. INTSV$ generates 
code to preserve R5 and R4 for the driver's use. All drivers must 
follow these conventions. 


See the description of the driver dispatch table in Section 4.5 for 
the contents of registers when a driver is entered. 


7.2 THE ADDRESS DOUBLE WORD 


RSX-11M-PLUS can accommodate configurations whose maximum physical 
memory is 2048K words. Individual tasks, however, are limited to 32K 
words. The addressing is accomplished by using virtual addresses and 
memory mapping hardware. I/O transfers, however, use. physical 
addresses 18 bits in length. Since the PDP-1ll word size is 16 bits, 
Some scheme is necessary to represent an address internally until it 
is actually used in an I/O operation. The choice was made to encode 
two words as the internal representation of a physical address and to 
transform virtual addresses for I/O operations into the internal 
doubleword format. 


On receipt of a QIO directive, the buffer address in the Directive 
Parameter Block, which contains a task virtual address, is converted 
to address doubleword format. 
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The virtual address in the DPB is structured as follows: 
Fits 0 through 5 Displacement in terms of 32-word blocks 
Fits 6 through 12 Block number 
Eits 13 through 15 Page Address Register Number (PAR#) 


The internal RSX-11M-PLUS translation restructures this virtual 
address into an address doubleword as described in the following 
paragraphs. 


The relocation base contained in the PAR specified by the PAR number 
in the virtual address in the DPB is added to the block number in the 
virtual address. The result becomes the first word of the address 
doubleword. It represents the nth 32-word block in a memory viewed as 
a collection of 32-word blocks. Note that at the time the address 
doubleword is computed, the user's task issuing the QIO directive is 
mapped by the processor's memory management registers. 


The sezsond word is formed by placing the displacement in block (bits 0 
througn 5 of virtual address) into bits 0 through 5. The block number 
field was accommodated in the first word and bits 6 through 12 are 
cleared. Finally, a6 is placed in bits 13 through 15 to enable use 
of PAR #6, which the Executive uses to service I/O for program 
transf2r devices. 


For noiprocessor request (NPR) devices, the driver requirements’ for 
manipulating the address doubleword are direct and are discussed with 
the description of U.BUF in Section 4.4.4. 


7.3 DRIVERS FOR NPR DEVICES USING EXTENDED MEMORY 


Special features must be built into drivers for non-MASSBUS NPR 
(nonprocessor request) devices attached to a PDP-11 processor with 
extend:d-memory support (22-bit addressing). 


Non-Ex‘:ended memory NPR devices on the PDP-11 processor must perform 
I/O transfers by using UNIBUS Mapping Registers (UMRS) as described in 
the PDP-11l Processor Handbook. One UMR is required for each 4K words 
involved in the transfer -- as specified by the contents of U.CNT in 
the UCB. When multiple UMRs are required for a transfer, they must be 
contigtious. 


A driver can be assigned UMRs through any one of three procedures: 


l. Dynamically allocating UMRs for the duration of the data 
transfer, or 


2. Dynamically allocating UMRs for longer periods of time, or 


3. Statically allocating UMRs during system generation. 


NOTE 


In large systems, use of the procedures 
above to hold UMRs for longer periods 
than necessary can result in the 
blocking of other drivers and a 
reduction in system throughput. 
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7.3.1 Calling $STMAP and S$MPUBM or S$STMP1 and $MPUB1 


To obtain UMRs through use of the SSTMAP and SMPUBM or the SSTMP1 and 
SMPUB1 routines, a driver must: 


e Have available six words for a mapping register assignment 
block in the 22-bit working storage area of the device's 
controller request block (KRB). The end of this area is 
accessed by adding the contents of K.OFF to the address at 
K.CSR. If the driver uses $STMP1 and SMPUB1, it must also 
have available a 10-word block 


e Call the routine S$STMAP or SSTMP1 (Set Up UNIBUS Mapping 
Address) atter getting the I/O packet 


e Call the routine SMPUBM or SMPUB1l (Map UNIBUS to Memory) 
before initiating a transfer 


These requirements are detailed in the following three subsections. 
Note that these routines are only required when the driver is 
performing a data transfer. 


7.3.1.1 Allocating a Mapping Register Assignment Block - The 
controller request block (KRB) of an NPR device requires a 6-word 
mapping register assignment block located in the 22-bit working 
Storage area. It does not have to be initialized. Any initial 
contents are simply overwritten. 


The following example shows the allocation of a mapping register 
assignment block. 


- BLKW M.LGTH ;UMR WORK AREA 


If the driver does not support parallel NPR operations requiring UMR 
mapping, it calls SSTMAP and $MPUBM. If the driver supports parallel 
NPR operations requiring UMR mapping, it must call SSTMP1l and SMPUB1. 
In the latter situation, the six additional words in the 22-bit 
working storage area are not used but must still be present. In 
addition, the driver data base must provide a 10-word mapping register 
assignment block for each data transfer to be mapped as specified in 
the description of $STMP1 later in Section 7.4.31. 


7.3.1.2 Calling S$STMAP or SSTMP1 - In the coding at the initiator 
entry point, after the call to SGTPKT, the NPR-device driver must call 
the routine S$STMAP or S$STMP1. These routines dynamically allocate 
required UMRs. If UMRsS are not available immediately, the driver is 
blocked. Such blocking, if it occurs, is completely transparent to 
the driver. The driver resumes processing at fork level when the UMRs 
have been allocated. The register returns are absolutely identical 
whether or not blocking has occurred. 


SSTMAP or S$STMP1 stores into U.BUF and U.BUF+2 (in the UCB) a UNIBUS 
address that causes the appropriate UMR to be selected for mapping the 
transfer. The call to SSTMAP or SSTMP1 must be conditionalized on 
MSSEXT. 


7.3.1.3 Calling SMPUBM or S$MPUB1 - Before executing the transfer, the 
driver must call S$MPUBM or SMPUB1l. These routines get the buffer's 
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22-bit physical address and load the UNIBUS mapping registers so that 
transfers are mapped directly to the task's space. The call to SMPUBM 
or SMPUB1 must be conditionalized on MSSEXT. 


If the driver calls SSTMAP and SMPUBM, the UMRs allocated to it are 
deallocated during the call to SIODON or S$IOALT. If the driver calls 
SSTMP1 and SMPUB1, it must call $DEUMR to deallocate any allocated 
UMRs before calling $IODON or S$IOALT. 


7.3.2 Calling SASUMR and $DEUMR 


Use of the procedure described in Section 7.3.3 assures that UMRS are 
always allocated. However, a driver may not’ require UMRS to be 
allocat.ed all of the time, and yet require UMRs for periods of time 
longer than the normal time-frame between S$GTPKT and SIODON (or 
SIOALT). In such cases, there is a third procedure for allocating 


UMRs. 


Through use of the Executive routines SASUMR and $DEUMR, a driver can 
dynamically allocate, retain over a desired time-frame, and deallocate 
UMRs. Refer to Section 7.4 for descriptions of the S$ASUMR and S$DEUMR 
routines. 


Similar to the SSTMAP/SMPUBM procedure, the use of SASUMR and S$DEUMR 
also requires the allocation of a 6-word mapping register assignment 
block. In this instance, however, the block must not be located in 
the 22-bit working storage area. S$IODON or $IOALT, when called, will 
attempt. to deallocate the UMRs of a block found in the 22-bit working 
Storage area. To avoid this deallocation, the mapping register 
assignment block could be dynamically allocated from the pool. Figure 
7-1 details the format of the 6-word block. 


M.LNK Link Word 

M.UMRA Address of first assigned UMR 

M.UMRN Number of assigned UMRs *4 

M.UMVL Low 16 bits mapped by first assigned UMR 
M.UMVH High 6 bits of High 2 bits mapped by 
M.BFVH physical buffer address UMR (in bits 4 and 5) 
M.BFVL Low 16 bits of physical buffer address 
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Figure 7-l: Mapping Register Assignment Block 


7.3.3 Statically Allocating UMRs During System Generation 

UMRS can be statically assigned during system generation. The system 
generation procedure defines the symbol NSSUMR equal to a fixed number 
of UMRs, multiplied by 4, that are statically assigned to the system. 
Before assembling the Executive, the user can cause _ the static 
allocation of an additional number of UMRs by editing tthe Executive 
assembly prefix file RSXMC.MAC. The value of the symbol NSSUMR can 
then be increased to represent the additional number of desired UMRs 
multiplied by 4. 
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further defines’ the 
first UMR statically 


The Executive assembly prefix file RSXMC.MAC 
following three symbols, which describe the 
allocated during system generation: 


USSMRN The I/O page address of the first UMR register 
available for allocation to the user 

USSMLO The low-order 16 bits of the 18-bit UNIBUS address 
mapped by this UMR 

USSMHI The high-order 2 bits of the 18-bit UNIBUS address; 


These three symbols are not used by the 
available for the user's infcrmation. 


these 2 bits are in bit positions 4 and 5 


system itself. They are 


SERVICE CALLS 


This section contains general commentary on _ the 
used by I/0 drivers. 
taken from the source code of modules linked to form the 

Table 7-1 summarizes the routines described in this section. 
used routines are 


typically 


widely 
Executive 


Routine 
Name 


SACHKB 
SACHCK 
SALOCB 
SASUMR 
SBLKCK 
SBLKC1 
SBLKC2 
SBLXIO 
SCKBFI 
SCKBFR 
SCKBFW 
SCKBFB 
SCLINS 
SCVLBN 
SDEACB 
SDEUMR 
SDVMSG 
SFORK 

SFORK1 
SGTBYT 
SGTPKT 
SGSPKT 
SGTWRD 
SINIBF 
SINTSV 
SINTXT 


services. are 
routines is in the MACRO-11 source files for the Executive modules. 


Executive routines 
The descriptions of the routines are 
Executive. 

Only the 
described; however, many other 


available. The source code for the related 


Table 7-1 


Summary of Executive Service Calls for Drivers 


Location in 
UFD [11,10] 


Function 


Adress check for byte-aligned buffers 
Address check for word-aligned buffers 
Alocate core buffer 

Assign UNIBUS mapping registers 

Check logical block number 

Check logical block number 

Check logical block number 

Move block of data 

Check I/0 buffer 

Check I/O buffer 

Check I/0 buffer 

Check I/0 buffer 

Clock queue insertion 

Convert logical block number 
Deallocate core buffer 

Deassign UNIBUS mapping registers 
Device message output 

Create a fork process 

Fork but bypass clearing timeout count 
Get byte 

Get an I/O packet 

Get a special I/O packet 

Get word 

Initiate I/O buffering 

Interrupt save and restore 

Interrupt exit 


(continued on next page) 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


Table 7-1 (Cont.) 
Summary of Executive Service Calls for Drivers 


Routine Location in 
Name UFD [11,10] Function 


SLOIALT Alternate entry to S$IODON 

SI DON I/O done for completing an I/O request 

SIJFIN I/O finish for special I/O completion 

$M 2UBM Map UNIBUS memory 

SM 2UB1 Alternate SMPUBM entry for parallel 
operations 

SPTBYT Put byte 

SP'TWRD Put word 

SQINSP Queue insertion by priority 

SR SLOC Relocate address 

SR SLOP Relocate UNIBUS physical address 

SRZIQUE Queue kernel AST to task 

$R2QU1 Queue kernel AST to task 

$S'TMAP Set up UNIBUS mapping address 

SS'TMP] Alternate $STMAP entry for parallel 
operations 

$T:SPAR Test if partition memory resident 
for kernel AST 

STSTBF Test for I/O buffering 
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$ACHKB 
S$ACHCK 


7.4.1 Address Check 


These routines are in the file IOSUB. A driver can call either 
routine to address-check a task buffer while the task is the current 
task. The Address Check routines are normally used only by drivers 
setting UC.QUE in U.CTL. See Section 8.3 for an example. 


Calling Sequences: 


CALL SACHKB 
or 
CALL SACHCK 
Description: 
7+ 
; **-SACHKB-ADDRESS CHECK BYTE ALIGNED 
3 **-SACHCK-ADDRESS CHECK WORD ALIGNED 
; 
; THIS ROUTINE IS CALLED TO ADDRESS CHECK A BLOCK OF MEMORY TO SEE WHETHER 
; IT LIES WITHIN THE ADDRESS SPACE OF THE CURRENT TASK. 
; 
; INPUTS: 
; 
i RO=STARTING ADDRESS OF THE BLOCK TO BE CHECKED. 
; R1=LENGTH OF THE BLOCK TO BE CHECKED IN BYTES. 
; 
; OUTPUTS: 
; 
; C=] IF ADDRESS CHECK FAILED. 
; C=0 IF ADDRESS CHECK SUCCEEDED. 
; 
; R2=ADDRESS OF WINDOW BLOCK MAPPING BUFFER 
; (FOR PRIV TASKS SEE NOTE.) 
; 
; RO AND R3 ARE PRESERVED ACROSS CALL. 
: NOTE: SINCE PRIVILEGED TASK I/O BUFFERS ARE NOT ADDRESS 
: CHECKED, R2 ALWAYS RETURNS A POINTER TO THE FIRST 
: WINDOW BLOCK. CHECKPOINTING AND SHUFFLING OF COMMONS 
; WILL STILL WORK PROPERLY PROVIDED THAT A PRIVILEGED 
; TASK NEVER SPECIFIES AN I/O INTO A COMMON WHICH IT 
7 ALLOWS TO REMAIN CHECKPOINTABLE AND SHUFFLEABLE. 
77 
Notes: 


In RSX-11M-PLUS Version 2.0, almost all drivers will wish to use 
the alternate routines S$CKBFB/$CKBFW which correctly maintain the 
attachment and partition I/0 count mechanism in addition to 
address checking the user buffer. If the driver completes all 
references to the buffer in the initiation routine (that is, 
fills the buffer and calls SIOFIN, rather than queueing the 
packet and/or starting a transfer which is completed via 
interrupt service) then it is permissible to use SACHKB/S$ACHCK. 
See Section 7.4.6 for a description of SCKBFB/SCKBFW and Section 
8.3 for an example. 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$ALOCB 


7.4.2 Allocate Core Buffer 
This routine is in the file CORAL. 
Calling Sequences: 
CALL SALOCB 
or 
CALL SALOC1 


Description: 


+ 


eeeSALOCB©ALLOCATE CORE BUFFER 
wweSALOCie ALLOCATE CORE BUFFER (ALTERNATE ENTRY) 


THIS ROUTINE IS CALLED TO ALLOCATE AN EXEC CORE BUFFER, THE ALLOCATION 
ALGORITHM IS FIRST FIT AND BLOCKS ARE ALLOCATED IN MULTIPLES OF FOUR 


BYTES, 
INPUTS 2 


R@SADDRESS OF CORE ALLOCATION LISTHEAD=e IF ENTRY AT SALOCI, 
R{sSIZE OF THE CORE BUFFER TO ALLOCATE IN BYTES, 


OUTPUTS: 


C=1 IF INSUFFICIENT CORE IS AVAILABLE TO ALLOCATE THE BLOCK, 
C=0 IF THE BLOCK IS ALLOCATED, 

R¥SADDRESS OF THE ALLOCATED BLOCK, 

RISLENGTH OF BLOCK ALLOCATED 


=e 78 te we Ye te Te te te Te TO we “se SS ws we 38 we te vO 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SASUMR 


7.4.3 Assign UNIBUS Mapping Registers 


This routine is in the file MEMAP. It is used only for PDP-11/70 NPR 
devices requiring UNIBUS Mapping Registers when 22-bit memory 
addressing is enabled. Normally, it is not called directly by an I/0 
driver. Rather, it is called from within the S$STMAP routine. Refer 
to Section 7.3 for a discussion. 


Calling Sequence: 
CALL SASUMR 


Description: 


+ 
wHOESASUMRE ASSIGN UNIBUS MAPPING REGISTERS 


THIS ROUTINE IS CALLED TO ASSIGN A CONTIGUOUS SET OF UMR°S, NOTE THAT 
FOR THE SAKE OF SPEED, THE LINK WORD OF EACH MAPPING ASSIGNMENT BLOCK 
POINTS TO THE UMR ADDRESS (2ND) WORD OF THE BLOCK, NOT THE FIRST WORD, 
THE CURRENT STATE OF UMR ASSIGNMENT IS REPRESENTED BY A LINKED LIST OF 
MAPPING ASSIGNMENT BLOCKS, EACH BLOCK CONTAINING THE ADDRESS OF THE 
FIRST UR ASSIGNED AND THE NUMBER OF UMR°S ASSIGNED TIMES 4, THE 
BLOCKS 4RE LINKED IN THE ORDER OF INCREASING FIRST UMR ADORESS, 


INPUTS? 


R@SPOINTER TO A MAPPING REGISTER ASSIGNMENT BLOCK, 
MSUMRA (CRU) SNUMBER OF UMK°S HKEQUIRED *» dU, 


OUTPUTSs 
ALL REGISTERS ARE PRESERVED, 


C=9 IF THE UMR°S WERKE SUCCESSFULLY ASSIGNED, 
ALL FIELDS OF THE MAPPING REGISTER ASSIGNMENT BLOCK 
ARE INITIALIZED AND THE BLOCK IS LINKED INTO 
THE ASSIGNMENT LIST, 
Cai TF Tre v4R*S COULD NOT BE ASSIGNED, 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$BLKCK 
$BLKC1 
$BLKC2 


7.4.4 Check Logical Block 


This routine is in the file MDSUB. The output from this routine is 
used by disk drivers as input to the $CVLBN routine to handle logical 
block numbers in data transfers. 


Callirg Sequence: 
CALL SBLKCK 
or 
CALL SBLKC2 
Descriotion: 
+ 
**-SBLKCK-LOGICAL BLOCK CHECK ROUTINE 


**-~SBLKC1-LOGICAL BLOCK CHECK ROUTINE (ALTERNATE ENTRY) 
**-~SBLKC2-LOGICAL BLOCK CHECK ROUTINE (ALTERNATE ENTRY FOR QUEUE OPT) 


me Ne 


THIS ROUTINE IS CALLED BY I/O DEVICE DRIVERS TO CHECK THE STARTING 
AND ENDING LOGICAL BLOCK NUMBERS OF AN I/O TRANSFER TO A FILE 
STRUCTURED DEVICE. IF THE RANGE OF BLOCKS IS NOT LEGAL, THEN SIODON 
IS ENTERED WITH A FINAL STATUS OF "TE.BLK" AND A RETURN TO THE 
DRIVER'S INITIATOR ENTRY POINT IS EXECUTED. ELSE A RETURN TO THE 
DRIVER IS EXECUTED. 


me Me ME Me Me Me MO te 


S$BLKC2 RETURNS TO SQOPDN IN SDROQRQ IF THERE IS AN ERROR INSTEAD OF 
THE DRIVER'S INITIATOR ENTRY POINT. THIS ALLOWS THE QUEUE 
OPTIMIZATION CODE TO USE BLKCK 


INPUTS: 


R1=ADDRESS OF I/0 PACKET. 
R5=ADDRESS OF THE UCB. 


OUTPUTS: 


IF THE CHECK FAILS, THEN SIODON IS ENTERED WITH A FINAL STATUS 
OF "IE.BLK" AND A RETURN TO THE DRIVER'S INITIATOR ENTRY POINT 
IS EXECUTED. 


IF THE CHECK SUCCEEDS, THEN THE FOLLOWING REGISTERS ARE RETURNED 
RO=LOW PART OF LOGICAL BLOCK NUMBER. 
R1=POINTS TO I.PRM+12 (LOW PART OF USER LBN) 
R2=HIGH PART OF LOGICAL BLOCK NUMBER. 
R3=ADDRESS OF 1/0 PACKET. 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$BLXIO 


7.4.5 Move Block of Data 
This routine is in file BFCTL. 
Calling Sequence: 

CALL SBLXIO 
Description: 


i+ 
a 
**-SBLXIO-MOVE BLOCK OF DATA. 


THIS ROUTINE IS CALLED TO MOVE DATA IN MEMORY IN A MAPPED SYSTEM. 
INPUTS: 


RO=NUMBER OF BYTES TO MOVE. 
R1=SOURCE APRS5 BIAS. 
R2=SOURCE DISPLACEMENT. 
R3=DESTINATION APR6 BIAS. 
R4=DESTINATION DISPLACEMENT. 


OUTPUTS: 


DESCRIBED MOVE IS ACCOMPLISHED. 

RO ALTERED 

R1,R3 PRESERVED 

R2,R4 POINT TO LAST BYTE OF SOURCE AND DESTINATION + 1] 
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NOTE: THE COUNT INPUT IN RO MUST NOT BE ZERO AND IT MUST NOT 
BE LARGE ENOUGH TO CROSS APR BOUNDARIES (THIS TYPICALLY 
MEANS A MAXIMUM OF 4K-63). 
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EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER 


$CKBFI 

$CKBFR 
$CKBFW 
$CKBFB 


7.4.6 Check I/O Buffer 
These vzoutines are in file EXESB. 
Calliny Sequences: 
CALL SCKBFB (or appropriate entry name) 
Descridtion: 
+ 
*k-~SCKBFI-CHECK I/O BUFFER FOR I-SPACE (OVERLAY) ACCESS 
**-SCKBFR-CHECK I/O BUFFER FOR READ-ONLY (BYTE) ACCESS 


**-SCKBFW-CHECK I/O BUFFER FOR READ-WRITE (WORD) ACCESS 
**-SCKBFB-CHECK I/O BUFFER FOR READ-WRITE (BYTE) ACCESS 


me Me NO 


THESE ROUTINES ARE CALLED TO ADDRESS CHECK AN I/0O BUFFER 
ASSOCIATED WITH THE CURRENT (UNDER CONSTRUCTION) I/O PACKET. 

IF THE ADDRESS CHECK PASSES, THEN AN ATTEMPT IS MADE TO POINT ONE 
OF THE ATTACHMENT DESCRIPTOR POINTERS AT THE ASSOCIATED ADB. THIS 
WILL HAVE ONE OF THE FOLLOWING OUTCOMES: 


1) - THERE IS CURRENTLY NO ATTACHMENT POINTER IN THE PACKET TO THIS 
ADB, AND THE POINTERS AREN'T FULL. A POINTER IS FILLED IN AND 
THE A.ICC, P.IOC FIELDS FOR THIS I/O ARE INCREMENTED. THIS IS 
THE "NORMAL" SUCCESSFUL CASE. 


2) - THERE IS ALREADY ONE POINTER TO THIS ADB. THE PACKET IS 
UNTOUCHED, AS ARE THE A.IOC AND P.IOC FIELDS, AND THE CHECK 
IS CONSIDERED SUCCESSFUL. THE IMPLICATION OF NOT INCREMENTING 
A.IOC AND P.IO0C IS THAT DRIVERS AND ACPS MAY NOT RELEASE 
BUFFERS FOR AN I/O REQUEST ONE AT A TIME, I.E. THE DRIVER 
SHOULD NOT CALL S$DECIO DIRECTLY, BUT SHOULD CALL SIODON OR 
SDECAL AFTER ALL BUFFER ACCESS HAS COMPLETED. 


3) - THERE ARE ALREADY TWO POINTERS, NONE OF THEM TO THIS ATTACHMENT 
DESCRIPTOR. THIS IS CONSIDERED A CHECK FAILURE AND RETURN 
IS MADE WITH CARRY SET. 


INPUTS: 
RO=STARTING ADDRESS OF BLOCK TO BE CHECKED 
R1=LENGTH OF BUFFER TO BE CHECKED 
SATTPT=ADDRESS OF I.AADA IN CURRENT I/O PACKET 
HEADER OF THE SUBJECT TASK IS MAPPED THROUGH KISAR6 


OUTPUTS: 
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C=0 CHECK AND PACKET UPDAT SUCCESSFUL 
I.AADA OR I.AADA+2 POINTS TO THE ADB 
A.IOC, P.IOC INCREMENTED 
C=] CHECK UNSUCCESSFUL OR PACKET COULD NOT BE FILLED IN 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$CLINS 


7.4.7 Clock Queue Insertion 
This routine is in the file QUEUE. 
Calling Sequence: 

CALL SCLINS 
Description: 


+ 
**-SCLINS-CLOCK QUEUE INSERTION 


THIS ROUTINE IS CALLED TO MAKE AN ENTRY IN THE CLOCK QUEUE. THE ENTRY 
IS INSERTED SUCH THAT THE CLOCK QUEUE IS ORDERED IN ASCENDING TIME. 
THUS THE FRONT ENTRIES ARE MOST IMMINENT AND THE BACK LEAST. 


INPUTS: 


RO=ADDRESS OF THE CLOCK QUEUE ENTRY CORE BLOCK. 
R1=HIGH ORDER HALF OF DELTA TIME. 

R2=LOW ORDER HALF OF DELTA TIME. 

R4=REQUEST TYPE. 

R5=ADDRESS OF REQUESTING TCB OR REQUEST IDENTIFIER. 


OUTPUTS: 


THE CLOCK QUEUE ENTRY IS INSERTED IN THE CLOCK QUEUE ACCORDING 
TO THE TIME THAT IT WILL COME DUE. 


NOTE: 
ON MULTIPROCESSOR SYSTEMS, A REQUEST WITH TYPE C.SYST!100000 
WILL BE EXECUTED ON A PRATICULAR UNIBUS RUN, WITH URM 
SPECIFIED IN C.URM. TYPE C.CYST REQUESTS ON MP SYSTEMS ARE 
DEFAULTED TO RUN ON ANY UNIBUS RUN, WHICH IN PRACTICE WILL 
RESULT IN THE REQUEST EXECUTING ON THE CPU WHICH OWNS THE 
CLOCK. (S$CKURM) 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$CVLBN 


7.4.8 Convert Logical Block Number 


This routine is in the file MDSUB. The input to this routine is the 
same as the output from the $BLKCK routine. Typically, a disk driver 
calls this routine to convert a logical block number to a = physical 
disk address. The routine accesses the U.PRM fields in the driver 
data base unit control block. These fields contain the sector, track, 
and cylinder parameters for the type of disk supported. Refer to the 
descriotion of the U.PRM fields in Section 4.4.4. 


Calliny Sequence: 
CALL SCVLBN 


Descriotion: 


+ 


weeS$CVLBN@CONVERT LOGICAL BLOCK NUMBER TO DISK PARAMETERS 


THIS SUBROUTINE wILL CONVERT THE SPECIFIED LOGICAL BLOCK NUMBER 
TO A SECTOR/TRACK/CYLINDER ADDRESS, 


INPUTS3 


(SAME AS SBLKCK OUTPUTS) 
R@sLOw PART OF LBN 
R2sHIGH PART OF LBN 
R33I1/0 PACKET ADDRESS 
RS2UCB ADDRESS 


OUTPUTS: 
R@2SECTOR NUMBER 


RIsTRACK NUMBER 
R2=CYLINDER NUMBER 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


7.4.9 Deallocate Core Buffer 
This routine is in the file CORAL. 
Calling sequences: 
CALL SDEACB 
or 
CALL SDEAC1 


Description: 


2 
wT 


weeSDEACB2DEALLOCATE CORE BUFFER 


IN THE FREE BLOCK CHAIN, 
INPUTS? 
RAZADDORESS OF THE CORE BUFFER 
RisSIZE OF THE CORE BUFFER TO 
R3sADDRESS OF CORE ALLOCATION 
OUTPUTS: 


THE CORE BLOCK IS MERGED INTO 
ADDRESS 449 TS AGCOMERATED IF 
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$DEACB 


weeS$DEACI@OEALLOCATE CORE BUFFER (ALTERNATE ENTRY) 


THIS ROUTINE IS CALLED TO DEALLOCATE AN EXEC CORE BUFFER, THE BLOCK IS 
INSERTED INTO THE FREE BLOCK CHAIN 8Y CORE ADORESS, IF AN ADJACENT 
BLOCK IS CURRENTLY FREE, THEN THE TwO BLOCKS ARE MERGED AND INSERTED 


TO BE DEALLOCATED, 
DEALLOCATE IM BYTES, 
LISTHEAD|©2 IF ENTRY AT $DEACI, 


THE FREE CORE CHAIN BY CORE 
NECESSARY wITr ADJACENT BLOCKS, 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$DEUMR 


7.4.10 Deassign UNIBUS Mapping Registers 
This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers when 22-bit addressing is enabled. 
Normally, it is not called directly by an I/O driver. Rather, it is 
callec from within the S$IODON routine. Refer to Section 7.3 for a 
discussion. 
Callirg Sequence: 

CALL SDEUMR 


Description: 


+ 


eRe SDEUMMOEDEASSTGN UNIBUS MAPPING REGISTERS 
THIS ROUTINE 15 CALLED Ti) NEASSIGN A CONTIGUOUS BLOCK OF UMR®°S, IF 
THE MAPPING ASSIGNMENT S8LOCK IS NOT IN THE LIST, NO ACTION IS TAKEN, 
NOTE THAT FOR THE SAKE OF ASSIGNMENT SPEED, THE LINK WORD POINTS TO 
THE UMR ADORESS (2ND) WORD UF TRE ASSIGNMENT BLOCK, 
INPUTS? 

R2@SsPOINTEK TO ASSIGN*YENT BLOCK, 
OUTPUTS3 


RY AND R{i ARE PRESERVED, 
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EXECUTIVE SERVICES AVAILABLE TO AN 1/0 DRIVER 


$DVMSG 


7.4.11 Device Message Output 
Device Message Output is in file IOSUB. 
Calling Sequence: 

CALL SDVMSG 


Description: 


a 
= 


eeOeSDVMSGeDEVICE MESSAGE OUTPUT 


THIS ROUTINE IS CALLED TO SUBMIT A MESSAGE TO THE TASK TERMINATION 
NOTIFICATION TASK, MESSAGES ARE EITHER DEVICE RELATED OR A CHECKPOINT 
WRITE FAILURE FROM THE LOADER, 


INPUTS$ 


R@SMESSAGE NUMBER, 
RSZADDRESS OF THE UCB OR TCB THAT THE MESSAGE APPLIES TO, 


OUTPUTS: 


A FOUR WORD PACKET IS ALLOCATED, R@ AND RS ARE STORED IN THE 
SECOND AND THIRD WORDS RESPECTIVELY, AND THE PACKET IS THREADED 
INTO THE TASK TERMINATION NOTIFICATION TASK MESSAGE QUEUE, 


NOTE: IF THE TASK TERMINATION NOTIFICATION TASK IS NOT INSTALLED 
OR NO STORAGE CAN BE OBTAINED, THEN THE MESSAGE REQUEST 
IS IGNORED, 


~e TO SO TO Ce TE ~O TE TO WH We TO ~“S TO TO TH BO VE TO TO =@E SE 


Note: 
Drivers use only two codes in calling S$DVMSG: T.NDNR (device not 
ready) and T.NDSE (select error). SDVMSG can be Set up and 
called as follows: 
MOV #T.NDNR, RO 


or 


MOV #T.NDSE,RO 
CALL SDVMSG 


EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER 


$FORK 


7.4.12 Fork 

Fork i3s in the file SYSXT. A driver calls SFORK to switch from a 
partiaily interruptable level (its state following a call on SINTSV) 
to a filly interruptable level. 

Calling sequence: 


CALL SFORK 


Description: 


+ 


weeSFORKeFORK AND CREATE SYSTEM PROCESS 


THIS ROUTINE IS CALLED FROM AN I/O DRIVER TO CREATE A SYSTEM PROCESS THaT 
WILL RETURN TO THE DRIVER AT STACK DEPTH ZERO TO FINISH PROCESSING, 


INPUTS? 
RSZADDRESS OF THE UCB FOR THE UNIT BEING PROCESSED, 
ACSP)SRETURN ADDRESS TO CALLER, 
2(SP)=SRETURN ADDRESS TO CALLERS CALLER, 
OU" PUTS: 
REGISTERS RS AND RY ARE SAVED IN THE CONTROLLER FORK BLOCK AND 


A SYSTEM PROCESS IS CREATED, THE PROCESS IS LINKED TO THE FORK 
QUEUE AND A JUMP TO SINTXT IS EXECUTED, 


we VO we TS TO MH we we Te Se Se BE TE “SO SO Te we we 


Notes: 


1. SFORK cannot be called unless SINTSV has been previously 
called or SINTSI has-~ run. The fork-processing routine 
assumes that the Executive has set up entry conditions. 


2. A driver's current timeout count is cleared in calls to 
SFORK. This protects the driver from synchronization 
Problems that can occur when an I/O request and the timeout 
for that request happen at the same time. After a return 
from a call to SFORK, a driver's timeout code will not be 
entered. 


If the clearing of the timeout count is not desired, a driver 
has two alternatives: 


a. Perform timeout operations by directly inserting elements 
in the clock queue (refer to the description of the 
SCLINS routine). 


b. Perform necessary initialization, including clearing 
S.STS in the SCB to zero (establishing the controller as 
not busy), and call the $FORK1 routine rather than $FORK. 
Calling SFORK1 bypasses the clearing of the current 
timeout count. 


3. The driver must not have any information on the stack when 
SFORK is called. 


EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER 


$FORK1 


7.4.13 Forkl 
Forkl is in the file SYSXT. A driver calls S$FORK1 to bypass the 
clearing of its timeout count when it switches from a partially 
interruptable level to a fully interruptable level (refer also to’ the 
description of the SFORK routine). 
Calling Sequence: 

CALL SFORK1 


Description: 


+ 


aeeSFORKILeEFORK AND CREATE SYSTEM PROCESS 


THIS ROUTINE IS AN ALTERNATE ENTRY TO CREATE A SYSTEM PROCESS AND 
SAVE REGISTER R5, 


INPUTS 3 


RUSADORESS OF THE LAST *ORD OF A 3 wORD FORK BLOCK PLUS 2, 
RSSREGISTER TO BE SAVED IN THE FORK BLOCK, 


OUTPUTS? 


REGISTER &5 IS SAvEfl Is THE SPECIFIED FORK BLOCK AND A SYSTEM 
PROCESS IS CREATED, THE PROCESS IS LINKED TU THE FORK QUEUE 
AND 4 JUMP TO SINTXT IS EXECUTED, 

R5 IS PRESERVED FOR CALLERS CALLER, 
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1. A 5-word fork block is required for calls to $FORK1. 


2. When a 5-word fork block is used, the driver must initialize 
the fifth word with the base address (in 32-word blocks) of 
the driver partition. This address can be obtained from the 
fifth word of the standard fork block in the SCB. 


3. The driver must not have any information on the stack when 
SFORK] is called. 


EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER 


$GTBYT 


7.4.14 Get Byte 


Get Byte is in the file BFCTL. Get Byte manipulates words U.BUF and 
U.BUF+2 in the UCB. 


Calling sequence: 
CALL SGTBYT 


Description: 


+ 


aweSGTBYT@GET "EXT BYTE FROM USER BUFFER 
THIS ROUTINE IS CALLED TO GET THE NEXT BYTE FROM THE USER BUFFER 
AND PETURPN IT TC THE CALLER ON THE STACK, AFTER THE BYTE HAS BEEN 
FETCHED, THE NEXT BYTE ADDRESS IS INCREMENTED, 
INPUTS3 

RSSANDRESS OF TRE UCB THAT CONTAINS THE BUFFER POINTERS, 
OUTPUTS: 


THE WEXT BYTE IS FETCHED FROM THE USER BUFFER AND RETURNED 
TU THE CALLER ON THE STACK, TRE NEXT BYTE ADDRESS IS INCREMENTED, 


ALL REGISTEXS ARE PRESERVED ACROSS CALL, 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


S$GTPKT 
$GSPKT 


7.4.15 Get Packet 


Get Packet and Get Special Packet are in the file IOSUB. The 
recommended way to use $GTPKT is to use the GTPKT$ macro call defined 
in Section 4.3. Usage of SGSPKT is described briefly in Section 
Oe ay 


Calling Sequences: 
CALL SGTPKT 
or 
CALL SGSPKT 


Description: 


+ 


**-SGTPKT-GET I/O PACKET FROM REQUEST QUEUE 
**-SGSPKT-GET SELECTIVE I/O PACKET FROM REQUEST QUEUE 


FROM THE CONTROLLER QUEUE. IF NO REQUEST CAN BE DEQUEUED, THEN A CARRY 
A CARRY CLEAR INDICATION IS RETURNED TO THE CALLER. 


IF QUEUE OPTIMIZATION IS SUPPORTED AND ENABLED FOR THE DEVICE 
THE APROPRIATE PACKET FOR THE CURRENT OPTIMIZATION ALGORITHM 

IS RETURNED. THREE ALGORITHMS ARE SUPPORTED: NEAREST CYLINDER, 
ELEVATOR, AND C-SCAN. ALL THREE ALGORITHMS INCORPORATE A 
FAIRNESS COUNT. IF THE FIRST PACKET ON THE LIST IS PASSED OVER 
MORE THAN "FCOUNT" TIMES, IT IS DONE IMMEDIATELY. 


THE ALTERNATE ENTRY POINT S$GSPKT IS INTENDED FOR USE BY DRIVERS WHICH 
SUPPORT PARALLEL OPERATIONS ON A SINGLE UNIT, A COMMON EXAMPLE BEING 
FULL DUPLEX. SUCH DRIVERS ARE EXPECTED TO LOOK TO THE SYSTEM AS IF 
THEY ARE ALWAYS FREE, WHILE MAINTAINING THE STATUS OF ALL PARALLEL 
OPERATIONS INTERNALLY WITHIN THEIR OWN DEVICE DATA STRUCTURES. 
PARALLELISM IS ACCOMPLISHED BY HANDLING DRIVER-DEFINED CLASSES OF I/0 
FUNCTION CODES IN PARALLEL WITH EACH OTHER. FOR EXAMPLE A FULL-DUPLEX 
DRIVER WOULD HANDLE INPUT REQUESTS IN PARALLEL WITH OUTPUT REQUESTS. 
A DRIVER CALLS $GSPKT WHEN IT WANTS TO DEQUEUE A PACKET WHOSE I/0 
FUNCTION CODE BELONGS TO A CERTAIN CLASS. WHICH FUNCTIONS QUALIFY IS 
DETERMINED BY AN ACCEPTANCE ROUTINE IN THE DRIVER WHOSE ADDRESS IS 
PASSED TO $GSPKT IN R2. THE ACCEPTANCE ROUTINE IS CALLED BY $GSPKT 
EACH TIME A PACKET IS FOUND IN THE QUEUE WHICH IS ELIGIBLE TO BE 
DEQUEUED. THE ACCEPTANCE ROUTINE IS THEN EXPECTED TO TAKE ONE OF THE 
FOLLOWING THREE ACTIONS: 
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1. RETURN WITH CARRY CLEAR IF THE PACKET SHOULD BE 
DEQUEUED. IN THIS CASE SGSPKT PROCEEDS AS S$GTPKT 
NORMALLY WOULD ON DEQUEUEING THE PACKET. 


2. RETURN WITH CARRY SET IF THE PACKET SHOULD NOT BE 
DEQUEUED,. IN THIS CASE SGSPKT WILL CONTINUE THE SCAN 
OF THE I/O QUEUE. 
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THIS ROUTINE IS CALLED BY DEVICE DRIVERS TO DEQUEUE THE NEXT I/O REQUEST TO 
PROCESS. IF THE DEVICE CONTROLLER IS BUSY, THEN A CARRY SET INDICATION IS 
RETURNED TO THE CALLER. ELSE AN ATTEMPT IS MADE TO DEQUEUE THE NEXT REQUEST 


SET INDICATION IS RETURNED TO THE CALLER. ELSE THE CONTROLLER IS SET BUSY AND 


SGTPKT 


$GSPKT (Cont.) 
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3. 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


ADD THE CONSTANT GSSSPSA TO THE STACK POINTER TO ABORT 
THE SCAN WITH NO FURTHER ACTION. 


THE ACCEPTANCE ROUTINE MUST SAVE AND RESTORE ANY REGISTERS WHICH IT 
INTENDS TO MODIFY. WHEN A PACKET IS DEQUEUED VIA SGSPKT, THE 
FOLLOWING NORMAL SGTPKT ACTIONS DO NOT OCCUR: 


NOTE: 


INPUTS: 


OUTPUTS: 


NOTE: 


FILLING IN OF U.BUF, U.BUF+2 AND U.CNT. THESE FIELDS 
ARE AVAILABLE FOR DRIVER-SPECIFIC USE. 


BUSYING OF UCB AND SCB. 


EXECUTION OF SCFORK TO GET TO PROPER PROCESSOR (MULTI- 
PROCESSOR SYSTEMS). 


SGSPKT MAY NOT BE USED BY A DRIVER WHICH SUPPORTS 
QUEUE OPTIMIZATION. 


R2=ADDRESS OF DRIVER'S ACCEPTANCE ROUTINE (IF CALL AT SGSPKT). 
R5=ADDRESS OF THE UCB OF THE CONTROLLER TO GET A PACKET FOR, 


C=1 IF CONTROLLER IS BUSY OR NO REQUEST CAN BE DEQUEUED. 
C=0 IF A REQUEST WAS SUCCESSFULLY DEQUEUED. 


R1=ADDRESS OF THE I/O PACKET. 
R2=PHYSICAL UNIT NUMBER. 

R3=CONTROLLER INDEX. 

R4=ADDRESS OF THE STATUS CONTROL BLOCK. 
R5=ADDRESS OF THE UNIT CONTROL BLOCK. 


R4 AND R5 ARE DESTROYED BY THIS ROUTINE. 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


7.4.16 Get Word 
Get Word is in the file BFCTL. It manipulates words U.BUF and U.BUF+2 
in the UCB. 


Calling Sequence: 


CALL SGTWRD 


Description: 
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+ 


ekROESGTWROWGET NEXT w»GRD FRO USER BUFFER 
THIS KOUTINE IS CALLED TO GET THE NEXT wORD FROM THE USER BUFFER 
ANDO RETURN IT TG THE CALLE® ON THE STACK, AFTER THE WORD HAS BEEN 
FETCHED, THE NEXT wORD ANDRESS IS CALCULATED, 
INPUTS3 

RSZaADORESS OF THE UCR THAT CONTAINS THE BUFFER POINTERS, 
OUTPUTS: 


THE NEXT wORD IS FETCHED FROM TRE USER BUFFER AND RETURNED 
TO THE CALLER ON THE STACK, THE NEXT WORD ADDRESS IS CALCULATED, 


ALL REGISTERS ARE PRESERVED ACROSS CALL, 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SINIBF 


7.4.17 Initiate I/O Buffering 
This routine is in the file IOSUB. 
Calling Sequence: 

CALL SINIBF 


Description: 


+ 


**-—-SINIBF-INITIATE I/O BUFFERING 
THIS ROUTINE INITIATES I/O BUFFERING BY DOING THE FOLLOWING: 
1. DECREMENT THE TASK'S 1/0 COUNT. 
2. INCREMENT THE TASK'S BUFFERED I/O COUNT 
3. INITIATE CHECKPOINTING IF A REQUEST IS PENDING 
INPUTS: 
R3=ADDRESS OF I/O PACKET FOR 1/0 REQUEST. 
OUTPUTS: 


R3 IS PRESERVED. 


=e me “oe Ne Me Me Me Se Ne NO Ne TO MO MO Me Me Me Ne tO 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SINTSV 


7.4.18 Interrupt Save 


Interrupt Save is in the file SYSXT. The recommended way to use 
SINTSV is to use the INTSVS macro call described in Section 4.3. 


Calling Sequence: 
CALL SINTSV, PRn 
n has a range of 0-7. 


Description: 


+ 


eee SINTSVOINTERPUPT SAVE 
#eOSINTSESINTERRUPT SAVE FOR ERRORLOGGING DEVICES 


THIS ROUTINE IS CALLED FROM AN INTERRUPT SERVICE ROUTINE wHEN AN 
INTERRUPT IS NOT GOING TO BE IMMEDIATELY DISMISSED, A SWITCH TO 

THE SYSTEM STACK I§ EXECUTED IF THE CURRENT STACK DEPTH IS ¢1, WHEN 
THE INTERRUPT SERVICE ROUTINE FINISHES ITS PROCESSING, IT EITHER FORKS 
» JUMPS TO $INTXT, OR EXECUTES & RETURN, 


INPUTS3 


4(SP)SPS wORD PUSHED 8Y INTERRUPT, 
2(SP)sPC wORD PUSHED BY INTERRUPT, 
@(SP)SSAVED RS PUSHED BY °JSR RS,SINTSV®, 
B(RS)SNEW PROCESSOR PRIORITY, 


OUTPUTS: 


REGISTER Ru JS PUSHED ONTO THE CURRENT STACK AND THE CURRENT 
STACK DEPTH IS DECREMENTED, IF THE RESULT IS ZERO, THEN 

A SwITCH TO THE SYSTEM STACK IS EXECUTED, THE NEW PROCESSOR 
STATUS IS SET AND A CO=ROUTINE CALL TO THE CALLER IS EXECUTED 
RY IS SET WITK THE CONTROLLER INDEX*2, WHICH IS DETERMINED 
FROM THE PSW AT ENTRY, 


we Te FO we te GO TSO YO TO CO TS TWO “Ee we TO BS TO TO GO we TE TO TE We we we 


Note: 


A system macro, INTSVS, is provided to simplify the coding of 
Standard interrupt entry processing. See Section 4.3. 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SINTXT 


7.4.19 Interrupt Exit 
Interrupt Exit is in the file SYSXT. 
Calline Sequence: 

JMP SINTXT 


Description: 


+ 


wee SINTXTS INTERRUPT EXIT 
THIS ROUTINE MAY BE CALLED VIA A JMP TO EXIT FROM AN INTERRUPT, 
INPUTS 
O2(SP)SINTERRUPT SAVE RETURN ADDRESS, 
OUTPUTS: 


A RETURN TO INTERRUPT SAVE IS EXECUTED, 


we ~e we we “8 we we ~e Te te ws ~e WO 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SIOALT/SIODON 


7.4.20 I/O Done Alternate Entry and I/O Done 
These routines are in the file IOSUB. 


Calling Sequences: 


CALL SIOALT 
CALL SIODON 


Description: 


+ 


wee BITOALTeI/0 DONE (ALTERNATE ENTRY) 
weeSTODON@I/O DONE 


THIS ROUTINE IS C4LLED BY DEVICE DRIVERS AT THE COMPLETION OF AN I/0 REQUEST 
TO DO FINAL PROCESSING, THE UNIT AND CONTROLLER ARE SET IDLE AND SIOFIN IS 
ENTERED TO FINISH THE PROCESSING, 


INPUTS? 
RU@sFIRST I/0 STATUS WORD, 


RLSSECOND 1/0 STATUS WORN, 
R@=sSTARTING AND FINAL ERROR RETRY COUNTS IF ERROR LOGGING 


DEVICE, 
RSZADDRESS OF THE UNIT CONTROL BLOCK OF THE UNIT BEING COMPLETED, 
(SP)SRETURN ANDRESS TO ORIVER’S CALLER, » TMA9S 


NOTE? IF ENTRY IS AT S$IOALT, THEN R} IS CLE4R TO SIGNIFY THAT THE 
SECOND STATUS *0R8D IS ZERO, 


NUTFUTS: 
THE UnIT AND CONTROLLER AWE SET ICLE. 


PSSANCRESS OF THE CURRENT I70 PACKET, 


we ma VE TO Me we SS SO TO BS BE Te UP TE BO ~“OH VO TO WH TE TO TO Ve Te Be We 


Note: 


R4 is destroyed when either of these routines is called. The 
routines call SIOFIN, which destroys R4. 


These routines push the address of routine S$DQUMR onto the stack 
before returning to the driver. This precludes the use of the 
stack for temporary data storage by drivers when calling these 
routines. 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SIOFIN 


724.21 I/O Finish 


I/O Firish is in the file IOSUB. Most drivers do not call I/O Finish, 
but you should be aware that this routine is executed when a driver 
calls SIOALT or SIODON. A driver that references an I/O packet before 
it is queued (bit UC.QUE set--see Section 8.3 for an example) calls 
I/O Finish if the driver finds an error while preprocessing the I/0 
packet. 


Calling Sequence: 
CALL SIOFIN 


Description: 


+ 


wee$TORFINel/O FINISH 


THIS ROUTINE IS CALLED TO FINISH I/70 PROCESSING IN CASES WHERE THE UNIT AND 
CONTROLLER ARE NOT TO BE DECLARED IDLE, IF THE TASK WHICH ISSUED THE 

1/0 HAS HAD A RECENT MAPPING CHANGE WHICH MAY HAVE UNMAPPED ITS 1/0 

STATUS BLOCK, THE I/O PACKET IS QUEUVED TO THE FRONT OF ITS AST QUEUE 

TO FE COMPLETED LATER IN SFINBF BY CALLING SIOFIN AGAIN, 


INPLTSs 

R@SFIRST J/0 STATUS WORD, 

R1=SECOND 1/0 STATUS wORD, 

R3SZADDRESS OF THE I/0 REQUEST PACKET, 
OUTFUTSs 

THE FOLLOWING ACTIONS ARE PERFORMED 


1eTHE FINAL 1/0 STATUS VALUES ARE STORED IN THE 1/0 STATUS BLOCK IF 
ONE WAS SPECIFIED, 


2eALL ASSOCIATED I/0 COUNTS ARE DECREMENTED AND TS,RDON IS 
CLEARED IN CASE THE TASK WAS BLOCKED FOR I/0 RUNDOWN, 
T3,MPC IS CLEARED IF THE TASK 1/0 COUNT GOES TO ZERO To 
INDICATE THAT THE I/O COUNT WENT TO ZERO AFTER A MAPPING 
CHANGE, 


3eIF °TS,CKR® IS SET, THEN IT IS CLEARED AND CHECKPOINTING OF 
THE TASK IS INITIATED, 


GeIP AN AST SERVICE ROUTINE waS SPECIFIED, THEN AN AST IS QUEVED 
FOR THE TASK, ELSE THE I/0 PACKET IS DEALLOCATED, 


SeA SIGNIFICANT EVENT OR EQUIVALENT IS DECLARED, 
NOTE’ RY IS DESTROYED BY THIS ROUTINE, 


wO SS NO TO TE TE TE TE TO TE SO TO TO we TO TE “Oe TE SS Te TO we TO WO Te TO Te Se te BO we “0 we we Ws we we wo 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$MPUBM 


7.4.22 Map UNIBUS to Memory 

This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers when 22-bit memory addressing is 
enabled. See Section 7.3 for a discussion. 

Calling Sequence: 


CALL SMPUBM 


Description: 


+ 


weeSMPUBM=MAP UNIBUS TO MEMORY 

THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE 
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN MEMe 
ORY ON AN 11/78 PROCESSOR WITH EXTENDED MEMORY, 

INPUTS? 


RUaADDRESS OF DEVICE SCB, 
RSaADDRESS OF DEVICE UCB, 


OUTPUTS: 


THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE TRANSFER 
ARE LOADED, 


NOTE: REGISTER R3 IS PRESERVED aCROSS CALL, 


we GO TO CS CE TO TO TO WO TE BO DH TE TSE TO @WE WO wo ~S 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$MPUB1 


7.4.23 Map UNIBUS to Memory (Alternate Entry) 

This routine is in file MEMAP. It is used only for NPR devices’ that 
require UNIBUS Mapping Registers when 22-bit memory addressing is 
enabled and for support parallel operations. 

Calling Sequences: 


CALL SM PUB 1 


Description: 


+ 


weeSMPUBL@MAP UNIBUS TO MEMORY (ALTERNATE ENTRY), 
THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE ORIVERS TO LOAD THE 
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN 
MEMORY ON AN 11/70 PROCESSOR WITH EXTENDED MEMORY, THIS ALTERNATE 
ENTRY POINT ALLOWS THE DRIVER TO SPECIFY A NON@STANDARD UMR MAPPING 
ASSIGNMENT BLOCK, 
INPUTS 3 

RYSADDRESS OF A UMR MAPPING ASSIGNMENT BLOCK, 
OUTPUTS? 


THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE 
TRANSFER ARE LOADED, 


NOTES "EGISTER #3 IS PRESERVED ACROSS CALL, 


we te FO he 4B Te wTS we TS we we we Ve se we TO HS we ~S we 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SPTBYT 


7.4.24 Put Byte 


Put Byte is in the file BFCTL. Put Byte manipulates words U.BUF and 
U.BUF+2 in the UCB. 


Calling Sequence: 
CALL SPTBYT 


Description: 


+ 


weeSPTBYT@PUT NEXT BYTE IN USER BUFFER 

THIS ROUTINE IS CALLED TO PUT A BYTE IN THE NEXT LOCATION IN 

USER BUFFER, AFTER THE BYTE HAS BEEN STORED, THE NEXT BYTE ADDRESS 
IS INCREMENTED, 

INPUTS? 


RSBADDRESS OF THE JCB THAT CONTAINS THE BUFFER POINTERS, 
2(SP)=BYTE TO BE STORED IN THE NEXT LOCATION OF THE USER BUFFER, 


CUTPUTS3s 


THE BYTE IS STORED IN THE USER BUFFER AND REMOVED FROM 
THE STACK, THE NEXT BYTE ADDRESS JS INCREMENTED, 


ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER 


$PTWRD 


7.4.25 Put Word 


Put Word is in the file BFCTL. It manipulates words U.BUF and U.BUF+2 
in the UCB. 


Calling Sequence: 
CALL SPTWRD 


Description: 
1¢ 
eee SPTWRD@PUT NEXT WORD IN USER BUFFER 
THIS ROUTINE IS CALED TO PUT &A WORD IN THE NEXT LOCATION IN 
USER BUFFER, AFTER THE WORD HAS BEEN STORED, THE NEXT WORD ADORESS 
TS CALCULATED, 


INPUTS3 


2(SP) WORD TO BE STORED IN THE NEXT LOCATION OF THE BUFFER, 
OUTPUTS3 


THE WORD IS STORED IN THE USER BUFFER AND REMOVED FROM 
THE STACK, THE NEXT WORD ADORESS IS CALCULATED, 


3 
; 
3 
; 
; 
; 
; 
} RS#ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS, 
} 
’ 
’ 
3 
’ 
’ 
; ALL REGISTERS ARE PRESERVED ACROSS CALL. 

; 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SQINSP 


724.26 Queue Insertion by Priority 
This routine is in the file QUEUE. A driver may call SQINSP to insert 
into the I/O queue an I/O packet that the Executive has not already 
placed in the queue. Queue Insertion by Priority is used only by 
drivers setting UC.QUE in U.CTL. See Section 8.3 for an example. 
Calling Sequence: 

CALL SQINSP 


Description: 


+ 


wHOSQINSPEQUEVE INSERTION BY PRIORITY 
THIS ROUTINE IS CALLED TO INSERT AN ENTRY IN A PRIORITY ORDERED 
LIST, THE LIST IS SEARCHED UNTIL AN ENTRY IS FOUND THAT HAS A 
LOWER PRIORITY OR THE END OF THE LIST IS REACHED, THE NEW 
ENTRY IS THEN LINKED INTO THE LIST AT THE APPROPRIATE POINT, 
INPUTS: 

ROSaODRESS OF THE TwO WORD LISTHEAD, 

RisADDRESS OF THE ENTRY TO BE INSERTED, 
OUTPUTS3 

THE ENTRY IS LINKED INTO THE LIST By PRIORITY, 


R@ AND R1 ARE PRESERVED ACROSS CALL, 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SRELOC 


7.4.27 Relocate 


Relocate is in the file MEMAP. A driver may call S$RELOC to relocate a 
task virtual address while the task is the current task. Relocate is 
normally used only by drivers setting UC.QUE in U.CTL. See Section 
8.3 for an example. 


Calling Sequence: 


CALL SRELOC 


Description: 


3+ 
wHeSRELOC*RELOCATE USER VIRTUAL ADDRESS 


we 


THIS ROUTINE IS CALLED TO TRANSFORM A 16 BIT USER VIRTUAL ADDRESS 
INTO A RELOCATION BIAS AND DISPLACEMENT IN BLOCK RELATIVE TO APRO, 


INPUTS? 
RQZUSER VIRTUAL ADDRESS TO RELOCATE, 
OUTPUTS?: 


RIZRELOCATION BIAS TO BE LOADED INTO PARb, 
R2sDISPLACEMENT IN BLOCK PLUS 140000 (PAR6 BIAS), 


R2 AND R3 ARE PRESERVED ACROSS CALL, 
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EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER 


SRELOP 


7.4.28 Relocate UNIBUS Physical Address 
This routine is in the file MEMAP, 


Calling Sequence: 


CALL SRELOP 


Description: 


+ 


weeSRELOP@RELOCATE UNIBUS PHYSICAL ADDRESS 


THIS ROUTINE RELOCATES A UNIBUS PHYSICAL ADDRESS TO & KISAR6 
BIAS AND DISPLACEMENT, 


INPUTS? 


ROSBYTE OFFSET FROM ADORESS IN U,BUF41 AND U,BUFF2 
R4sSCB ADDRESS 
RSeUCB ADDRESS 
U,BUF¢1(RS)SHIGH ORDER BITS OF PHYSICAL ADDRESS 
U,B8UF+2(R5)=LOw ORDER BITS OF PHYSICAL ADDRESS 


OUTPUTS? 


KISAROBSCALCULATED BIAS (MAPPED SYSTEM) 
RiBREAL ADDRESS OR DISPLACEMENT 
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EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER 


$REQUE 
$REQU1 


7.4.29 Queue Kernel AST to Task 
This routine is in module IOSUB. 
Calling Sequence: 

CALL SREQUE 
or 

CALL SREQU1 


Description: 


© nin 


;**-SREQUE-REQUEUE A REGION LOAD AST TO A TASK AST 
;**-SREQU1-REQUEUE A REGION LOAD AST TO A TASK AST (ALTERNATE ENTRY) 


THESE ROUTINES ARE USED TO QUEUE A TASK KERNEL AST WHICH HAS BEEN 
USED AS A REGION LOAD AST BACK AS A TASK AST. THE BUFFERED I/O 
COUNT OF THE TASK IS DECREMENTED IF ENTRY AT SREQUE. 


INPUTS: 
RO=TCB ADDRESS OF ASSOCIATED TASK 


R3=ADDRESS OF PACKET TO BE QUEUED 


OUTPUTS: 
NONE. 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$STMAP 


7.4.30 Set Up UNIBUS Mapping Address 


This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers when 22-bit memory addressing is 
enabled. See Section 7.3 for a discussion. 


Calling Sequence: 
CALL SSTMAP 


Description: 


j *#ee$STMAPeSET UP UNIBUS MAPPING ADDRESS 


ps THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE ORIVERS TO SET UP THE 

t UNIBUS MAPPING ADDRESS, FIRST ASSIGNING THE UMR°S, IF THE UMR®°S 

: CANNOT BE ALLOCATED, THE DRIVER’S MAPPING ASSIGNMENT BLOCK IS PLACED 
tf IN A WATT QUEUE AND A RETURN TO THE DRIVER’S CALLER I8 EXECUTED, THE 
¢ ASSIGNMENT BLOCK WILL EVENTUALLY BE DEQUEUED WHEN THE UMR°S ARE 

t AVAILABLE AND THE ORIVER wILL BE REMAPPED AND RETURNED TO WITH RieRS 
sy PRESERVED AND THE NORMAL OUTPUTS OF THIS ROUTINE, THE ORIVER®’S 

¢ CONTEXT IS STORED IN THE ASSIGNMENT BLOCK AND FORK BLOCK WHILE IT I8 
; BLOCKED AND IN THE WAIT QUEUE, ONCE A DRIVER®’S MAPPING ASSIGNMENT 

9 BLOCK IS PLACED IN THE UMR WAIT QUEUE, IT IS NOT REMOVED FROM THE 

9 QUEUE UNTIL THE UMR°S ARE SUCCESSFULLY ASSIGNED, THIS STRATEGY 

# ASSURES THAT WAITING DRIVERS WILL BE SERVICED FIFO AND THAT DRIVER'S 
y WITH LARGE REQUESTS FOR UMR°S WILL NOT WAIT INDEFINATELY, 


» INPUTS? 


R4ZADDRESS OF DEVICE SCB,. 
H RSsaAODRESS OF DEVICE UCB, 
H (SP)ZRETURN TO ORIVER’S CALLER, 


¢ OUTPUTS3 


UNIBUS MAP ADDRESSES ARE SET UP IN THE DEVICE UCB AND THE 
: ACTUAL PHYSICAL ADDRESS IS MOVED TO THE SCB, 


’ 
§ NOTE: REGISTERS Ri, R2, AND R3 ARE PRESERVED ACROSS CALL. 


0 
7” 


Note: 


This routine pushes the address of routine S$DQUMR+2 onto’ the 
stack before returning to the caller. This precludes the use of 
the stack for temporary data storage by drivers when calling this 
routine. 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


SSTMP1 


Tete od 


This routine is in file MEMAP., 


requir? UNIBUS 
enabled and for support parallel operations. 


Mapping Registers when 


Calliny Sequence: 


Descr 


Note: 


CALL 


iption: 


+ 


BLOCK 
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This routine pushes the address 
stack before returning to the caller. 


SSTMP1 


Set Up UNIBUS Mapping Address (Alternate Entry) 


It is used only for NPR devices that 


22-bit memory addressing is 


seeSSTMPLeSET UP UNIBUS MAPPING ADDRESS (ALTERNATE ENTRY), 


THIS ENTRY CODE SETS UP AN ALTERNATE DATA STRUCTURE USED AS 
A UMR MAPPING ASSIGNMENT BLOCK AND CONTEXT STORAGE BLOCK, IN 
THE SAME MANNER AS $STMAP USES THE FORK BLOCK AND MAPPING 


IN THE SCB, KRB, THE FORMAT OF THE STRUCTURE IS AS FOLLOWS: 


H i 
i I 
! t 
I ! 


| i 
$ i 
} 4 
i t 
t ! 
H I 


INPUTS? 


4 WORDS USED FOR SAVING 
ORIVER’S CONTEXT IN CASE 
UMRS CAN°T BE MAPPED 
IMMEDIATELY, 


6 WORDS USED AS A UMR 
MAPPING ASSIGNMENT BLOCK, 


RB=ANDRESS OF THE DATA STRUCTURE DEPICTED ABOVE, 


R4=aDDRESS OF NEVICE SCB, 
RSSADDRESS OF OEVICE UCR, 


QUTPUTS? 


DATA STRUCTURE POINTERS SET UP FOR ENTRY TO SSTMP2 IN SSTMAP, 


of 


routine SDQUMR+2 onto’ the 


This precludes the use of 


the stack for temporary data storage by drivers when calling this 


routine. 


7238 


EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$STSPAR 


7.4.32 Test if Partition Memory Resident for Kernel AST 
This routine is in file REQSB. 


Calling Sequence: 
CALL STSPAR 
Description: 
*k—~STSPAR-TEST IF PARTITION IS IN MEMORY FOR KERNEL AST 


THIS ROUTINE IS CALLED TO CHECK A REGION FOR MEMEORY RESIDENCE 
TO DETERMINE IF IT IS SAFE TO SERVICE A KERNEL AST (E.G. COPY 
A BUFFER) INTO THE REGION. IF THE REGION IS CHECKPOINTED OR 
CURRENTLY BEING CHECKPOINTED, THEN A REGION LOAD AST IS QUEUED 
AND THE REGION IS ACCESSED ON THE TASKS BEHALF. 


INPUTS: 
RO=ADDRESS OF PACKET PEING PROCESSED 
R1=PCB ADDRESS OF REGION 
R5=TCB ADDRESS OF ASSOCIATED TASK 


OUTPUTS: 
C=0 IF REGION IS MEMORY RESIDENT 
C=1 IF REGION IS NON-RESIDENT. IN THIS CASE THE REGION AST 
HAS BEEN QUEUED, ETC. 
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EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER 


$TSTBF 


7.4.33 Test for I/O Buffering 
This routine is in file IOSUB. 
Calling Sequence: 

CALL STSTBF 


Description: 


+ 


**-STSTBF-TEST IF I/O BUFFERING CAN BE INITIATED 
THIS ROUTINE DETERMINES IF A GIVEN I/O REQUEST IS ELIGIBLE FOR I/0 
BUFFERING, AND IF SO IT STORES THE PCB ADDRESS OF THE REGION INTO 
WHICH THE TRANSFER IS TO OCCUR IN I.PRM+16 OF THE I/O PACKET. 
INPUTS: 

R3=ADDRESS OF I/O PACKET FOR I/O REQUEST 
OUTPUTS: 

R3 IS PRESERVED. 

C=0 IF I/O BUFFERING CAN BE INITIATED. 


C=1 IF I/O BUFFERING CAN NOT BE INITIATED. 
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CHAPTER 8 


SAMPLE DRIVER CODE 


This chapter presents three sections of code. Sections 8.1 and 8.2 
show the driver data base and driver code for a conventional driver. 
Section 8.3 gives a coding example from a driver that inhibits’ the 
automatic packet queuing in QIO processing so that it might 
address-check and relocate a special user buffer. Both of the sample 
drivers are in UFD [200,1] on the distribution kit. 


In addition to the examples shown in this chapter, you should review 
the source code for one or more standard DIGITAL-supplied drivers. 


You should also examine the files SYSTB.MAC and XXTAB.MAC, which 
contain data structures created at system generation. 


8.1 SAMPLE DRIVER DATA BASE 
The following example shows the source code to create the data base 


for the driver that supports the DL device. The data base allows for 
one controller and one unit. 


-TITLE DLTAB 
-IDENT /09.0/ 
SYSTEM TABLES 


MACRO LIBRARY CALLS 


=e te te Te TE 


-MCALL CLKDFS 
-MCALL HWDDFS 
-MCALL SCBDFS 
-MCALL UCBDFS 


CLKDFS$ ;DEFINE CLOCK BLOCK OFFSETS 
HWDDFS ;DEFINE HARDWARE REGISTERS 
SCBDF$ ,,SYSDEF ;DEFINE SCB OFFSETS 
UCBDFS$ ;DEFINE UCB OFFSETS 
? 
; 
? 
SDLDAT:: 
: 
; DL CTB 
i 
-WORD 0 ; L.ICB 
SCTBO: 
~WORD SCTB1 ; L.LNK 
-ASCII /DL/ ; L.NAM 
-WORD .DCO ; L.DCB 
~BYTE 1 ; L.NUM 


~BYTE 
SDLCT3B:: 
~WORD 


. 
’ 


SDLTBIL=0 
SDLDCB:: 
-DCO: 
. WORD 
.-WORD 


ASCII 


-BYTE 
-WORD 
«WORD 
-WORD 
-WORD 


-WORD 


-WORD 
-WORD 
BYTE 
-BYTE 
-WORD 
-WORD 
-WORD 
-WORD 
-WORD 
-WORD 
~-BYTE 
-WORD 
DLND=. 


we Me Ne 


«BYTE 
-BYTE 
~-BYTE 
«WORD 
-WORD 
-WORD 
-BYTE 
-WORD 


SDLA?:: 


SDLO:: .WORD 
-WORD 
~WORD 
-WORD 
-BYTE 
~BYTE 
-BYTE 
~-BYTE 
~WORD 
~WORD 
-BYTE 
~-BYTE 
«WORD 
- BLKW 
~WORD 
DLA: 


SAMPLE DRIVER CODE 


SDLA 


spel 
. DLO 

/DL/ 

0,0 
DLND-DLST 
SDLTBL 


L.STS 
L.KRB 


~e Ne 


DL DCB 


; LOADABLE DLDRV 


D.LNK 
D.UCB 
D.NAM 
D.UNIT 
D,UCBL 
; D.DSP 


es ™%e ee BO NS NS 


177477,70,0,177200,377,0,0,377 ; D.«MSK 


0 


0 


- DCO 
e -2 


; D.PCB 


DL UCB'S 


UC.ALG!UC.NPR!IUC. PWF!1,US.MNT 


0,US.OFL 


DV.DIR!IDV.MSD!DV. UMD!DV.F11!DV.MNT 


0 
50000 
512. 
SDLO 


0,0,0,0,0,0,0,0 


40.,2. 
512. 


PR5 
160/4 
0*2,0 
O!KS.OFL 
174400 
DLA-~SDLA 
0,0 

0 


CONTIGUOUS 5 C B 


Oe 
~ 
on 
= 

© 


= = 


oo npnooo°o °o 


S$2.LOG!S2.CON 
SDLA 


oOnoOo ~ 


DLA KRB 


K.PRI 
K.VCT 
K.CON, K.IOC 
K.STS 
K.CSR 
K. OFF 
K.HPU 
K. OWN 


me Me Me MO Me MO MO NO 


HERE FOR DL 


S.LHD AND K.CRQ 
S.FRK 

S.KS5 

S.PKT 

S.CTM 

S.ITM 

S.STS 

S.553 

S.ST2 

S.KRB 

S.RCNT 

S.ROFF 

S.EMB 

MAPPING ASSIGNMENT BLOCK 
KE.RHB 
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SAMPLE DRIVER CODE 


-DC1 = 0 ; END OF DCB LIST FOR DL: 


SCTB1 = 0 ; END OF CTB LIST FOR DL: 


8.2 SAMPLE DRIVER CODE 


The following example shows the source code for the DL driver. 
Comments beginning with ';;;' indicate that the instruction is being 
executed at a priority level greater than or equal to 5. 


-TITLE DLDRV 
-IDENT /01/ 


; RL11-RLO1/02 DISK DRIVER 


* 
‘ 


-MCALL HWDDFS,PKTDFS 
HWDDFS$ ;DEFINE HARDWARE REGISTERS 
PKTDFS ;DEFINE I/O PACKET OFFSETS 


; EQUATED SYMBOLS 


e 


RETRY= 8. ;CONTROLLER ERROR RETRY COUNT 
RLBPT= 512.¥*20. ;BYTES PER SURFACE 
RLSPU= 15. ;TIME TO SPIN UP 


; RL11 DEVICE REGISTER OFFSETS 


° 
‘ 


RLCS= 0 CONTROL STATUS REGISTER 
RLBA= 2 7BUS ADDRESS REGISTER 
RLDA= 4 DISK ADDRESS REGISTER 
RLMP= 6 ;MULTIPURPOSE REGISTER 


; RLCS BIT ASSIGNMENTS 


. 
‘ 


ERR= 100000 ;COMPOSITE ERROR 

DE= 040000 ;DRIVE ERROR 

NXM= 020000 ;NONEXISTENT MEMORY 
DLT= 010000 ;DATA LATE 

HNF= 010000 ;HEADER NOT FOUND 

DC K= 004000 ;DATA CHECK ERROR 
HCRC= 004000 ;HEADER CRC ERROR 

OPI= 002000 ; OPERATION INCOMPLETE 
DRDY= 1 ;DRIVE READY 

WCHK= 2 ;WRITE CHECK FUNCTION 
WRITE= 2 ;WRITE OFFSET 

GSTS= 4 GET DRIVE STATUS FUNCTION 
SEEK= 6 ;SEEK FUNCTION 

RDH= 10 ;READ HEADERS FUNCTION 
READ= 14 7;READ DATA FUNCTION 


SAMPLE DRIVER CODE 


IE= 100 ; INTERRUPT ENABLE 
CRDY= 200 ;CONTROLLER READY 


me Me we 


RLDA STATUS CODES 


MRK= 1 ;MARKER BIT 
STS= 2 ;GET STATUS BIT 

SN= 4 ;SIGN BIT FOR SEEK 

RST= 10 ;DRIVE RESET BIT 

HS= 20 ;HEAD SELECT BIT FOR DIFFERENCE 
REV= 200: MRK ;REVERSE SEEK DIFFERENCE WORD 


™e te Ne 


RLMP GET STATUS BIT ASSIGNMENTS 


WDE= 100000 ;WRITE DATA ERROR 

CHE= 040000 ;CURRENT HEAD ERROR 

WLS= 020000 ;WRITE LOCK STATUS 

SKTO= 010000 ;SEEK TIMEOUT ERROR 

SPD= 004000 SPEED ERROR 

WGE= 002000 ;WRITE GATE ERROR 

vc= 001000 ; VOLUME CHECK 

DSE= 000400 ;DRIVE SELECT ERROR 

DT= 000200 ;DRIVE TYPE 

HSS= 000.00 ;HEAD SELECT STATUS 

CO= 000040 ;COVER OPEN 

HH= 000020 ;HEADS HOME 

BH= 000010 ;BRUSHES HOME 

SLM= 000005 ;DRIVE IN SEEK-LINEAR MODE STATE 
LOCAL DATA 


me we TE We Be WE 


CONTROLLER IMPURE DATA TABLES 
THESE ARE INDEXED BY THE CONTROLLER NUMBER 


RTTBL: .BLKW RS$L11 ;RETRY COUNT FOR CURRENT OPERATION 
PRMSV: .BLKW RS$L1145 ; PARAMETER SAVE AREA FOR WRITE CHECK 


me “ee te 
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+ 


DRIVER DISPATCH TABLE 


DDTS DL,RS$L11,NEW=Y ;GENERATE DISPATCH TABLE 


**-DLINI-RL11-RLO1/02 DISK CONTROLLER INITIATOR 


THIS ROUT(NE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O 
REQUEST IS QUEUED AND AT THE END OF A PREVIOUS I/O OPERATION TO 
PROPAGATE THE EXECUTION OF THE DRIVER. IF THE SPECIFIED CONTROLLER 
IS NOT BUSY, THEN AN ATTEMPT IS MADE TO DEQUEUE THE NEXT I/O REQUEST. 
ELSE A RETURN TO THE CALLER IS EXECUTED. IF THE DEQUEUE ATTEMPT 

IS SUCCESSFUL, THEN THE NEXT I/O OPERATION IS INITIATED. A RETURN 
TO THE CALLER IS THEN EXECUTED. 


INPUTS: 
R5= ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 


OUTPUTS: 
IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS 
WAITING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE 


DLINI: 


me ™O M8 Me Me MO NO Me MO Me we TO TO TH MO MO Ne Me NO NS Ne Ne Se Me TH TO ME ME TO Ne NS TO Me NO OMS 


5$ 
10S: 


20S: 


SAMPLE DRIVER CODE 


DRIVER INITIATES THE REQUESTED I/O FUNCTION 


GTPKTS DL,RS$S$L11 ;GET NEXT I/O PACKET TO PROCESS 


Rl= 
R2= 
R3= 
R4= 
R5= 


THE FOLLOWING ARGUMENTS ARE RETURNED BY SGTPKT: 


ADDRESS OF THE I/O REQUEST PACKET 

PHYSICAL UNIT NUMBER OF THE REQUESTED DRIVE 
CONTROLLER INDEX 

ADDRESS OF THE STATUS CONTROL BLOCK 

ADDRESS OF THE UCB OF THE DRIVE TO BE INITIATED 


RL11-RLO1/02 


DRIVER USAGE 


DISK CONTROLLER I/O REQUEST PACKET FORMAT: 


WD. 00 -- I/0 QUEUE THREAD WORD 

WD. 01 -- REQUEST PRIORITY, EVENT FLAG NUMBER 

WD. 02 -- ADDRESS OF THE TCB OF THE REQUESTOR TASK 

WD. 03 -- POINTER TO 2ND LUN WORD IN REQUESTOR TASK HEADER 

WD. 04 -~- CONTENTS OF FIRST LUN WORD 

WD. 05 -- I/O FUNCTION CODE 

WD. 06 -- VIRTUAL ADDRESS OF I/O STATUS BLOCK 

WD. 07 -- RELOCATION BIAS OF I/O STATUS BLOCK 

WD. 10 -- I/0 STATUS BLOCK ADDRESS (DISPLACEMENT + 140000) 

WD. 11 -- VIRTUAL ADDRESS OF AST SERVICE ROUTINE 

WD. 12 -- MEMORY EXTENSION BITS OF I/O TRANSFER 

WD. 13 -- BUFFER ADDRESS OF I/O TRANSFER 

WD. 14 -- NUMBER OF BYTES TO BE TRANSFERRED 

WD. 15 -- NOT USED. 

WD. 16 -- LOW BYTE MUST BE ZERO AND HIGH BYTE IS NOT USED 

WD. 17 -- LOW PART OF LOGICAL BLOCK NUMBER OF I/0 REQUEST 

WD. 20 -- RELOCATION BIAS OF REGISTER BUFFER ELSE NOT USED 

WD. 21 -- REGISTER BUFFER ADDRESS (DISPLACEMENT + 140000) ELSE NOT USED 
OF WORDS IN I/O PACKET: 

I.PRM+6 (WD. 15) - SEEK DIFFERENCE WORD 

I.PRM+10 (WD. 16) - STARTING DISK ADDRESS FOR THIS TRANSFER 

I.PRM+12 (WD. 17) - BYTE COUNT FOR THIS TRANSFER 

MOV #RETRY&377,RTTBL(R3) ;SET INITIAL RETRY COUNT 

CALL S$VOLVD ; VALIDATE VOLUME VALID 

BCS 5$ ;IF CS WE FAILED 

TST RO TRANSFER FUNCTION? 

BMI 10$ ;IF MI YES 

TST I. PRM+2 (R1) ;SIZE THE DISK? 

BPL 5$ ;IF PL NO, ERROR 

MOV S.CSR(R4) ,R2 ;RETRIEVE CSR ADDRESS 

CALL DLRST ;RESET DRIVE AND GET STATUS 

MOV S.PKT(R4) ,R3 ;RETRIEVE I/O PACKET ADDRESS 

MOV I.PRM+14(R3),KISAR6 ;SET BUFFER RELOCATION BIAS 

MOV I.PRM+16(R3),R3 ;GET REGISTER BUFFER ADDRESS 

CALL REGPAS sMOVE REGISTERS INTO BUFFER 

IMP DLFIN ;FINISH UP 

CALL SSTMAP ;SET UP UNIBUS MAPPING ADDRESS 

MOVB R2,U.BUF+1(R5) ;SET CURRENT UNIT NUMBER 

MOV #IE.IFC&377,RO ;ASSUME ILLEGAL FUNCTION 

BIS #READ!IIE,U.BUF(R5) ;ASSUME READ LOGICAL FUNCTION 

CMPB #10.RLB/256.,1.FCN+1(R1) ;REALLY? 

BEQ 20$ ;IF EQ YES 

CMPB #I0.WLB/256.,1.FCN+1(R1) ;WRITE LOGICAL FUNCTION? 

BNE 5$ ;IF NE NO, EXIT WITH ERROR 

SUB #WRITE,U.BUF(R5) ;CONVERT TO WRITE LOGICAL FUNCTION 

MOV #RETRY,RTTBL(R3) ;SET INITIAL RETRY COUNT 


SAMPLE DRIVER CODE 


MOV I.PRM+12(R1),RO ;RETRIEVE BLOCK NUMBER 

Cha R2 ;CLEAR HIGH ORDER BLOCK NUMBER 

BITB #I0.WPB&377,I.FCN(R1) ;PHYSICAL BLOCK FUNCTION? 

BN? 35$ ;IF NE YES 

CALE SBLKCK ;CHECK LOGICAL BLOCK NUMBER 

CM >B #I10.WLB/256.,1I.FCN+1(R3) ;WRITE FUNCTION? 

BN2 30$ ;IF NE NO 

BIB #I10.WLT&377,1.FCN(R3)  ;OK TO WRITE ON LAST TRACK? 

BN? 30$ ;IF NE YES 

MOV RO,I.PRM+6(R3) ;YES, SAVE STARTING BLOCK NUMBER 

AD) #*D<20>,1I.PRM+12(R3)  ;ADD 1 TRACK'S WORTH OF BLOCKS 

CALL SBLKC1 ;CHECK IF WRITE ON LAST TRACK OF DISK 

MO’/ I.PRM+6(R3),RO ;RESTORE ORIGINAL STARTING BLOCK NUMBER 
30$: AS: RO ;CONVERT BLOCKS TO SECTORS 
358: MO’? S.PKT(R4) ,R3 ;RESET I/O PACKET ADDRESS 

CALL SCVLBN ;CONVERT BLOCK NUMBER TO DISK ADDRESS 

ROR Rl ;PUT SURFACE BIT IN CARRY 

ROL R2 ;MERGE IT WITH THE CYLIDER NUMBER 

ASH #6,R2 ;POSITION CYLINDER AND SURFACE 

BIS RO,R2 ;MERGE SECTOR WITH CYLINDER AND SURFACE 

MOY R2,1.PRM+10(R3) ;SAVE STARTING DISK ADDRESS 

MOV U.CNT(R5),I.PRM+12(R3) ;ASSUME ONLY ONE XFER NEEDED 

MOV #*D<40>,R1 ;SET SECTORS/SURFACE 

SUB RO,R1 ;CALCULATE SECTORS LEFT ON SURFACE 

SWAB Rl ;GET BYTES LEFT ON SURFACE 

CMP U.CNT(R5),R1 ;ARE ADDITIONAL TRANSFERS REQUIRED? 

BLOS 40$ ;IF LOS NO 

MOV Rl,I.PRM+12(R3) ;SET BYTE COUNT FOR FIRST TRANSFER 
40S: MO\B S.CON(R4) ,R1 ;RETRIEVE CONTROLLER INDEX 

MUL #5,R1 ;FORM INDEX INTO PARAMETER SAVE AREA 

ADI #PRMSV,R1 ;POINT TO THIS ENTRY 

MOV U.BUF(R5),(R1)+ ;SAVE INITIAL PARAMETERS 

MOV U.BUF+2(R5),(Rl)+ ;... 

MOV U.CNT(R5),(R1)+ jee. 

MOV I.PRM+10(R3),(R1)+ ;... 

MOV I.PRM+12(R3),(R1)+ 7... 


THIS SECTION WILL INITIATE THE OPERATION 
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DLINIO: CALL $MPUBM ;MAP UNIBUS TO TRANSFER 
MOV S.CSR(R4) ,R2 ;GET ADDRESS OF CSR 
MOV S.PKT(R4) ,R3 ;GET ADDRESS OF I/O PACKET 
CLRB U.CW2+1(R5) ;RESET DRIVE SETTLE DOWN FLAG 
CLR I. PRM+6 (R3) ;RESET ERROR DIFFERENCE WORD 
MOVB S.ITM(R4),S.CTM(R4) ;SET DEVICE TIMEOUT COUNTER 
CALL DLRST ;RESET DRIVE AND GET STATUS 
MOV RLMP(R2) ,R1 ;GET THE STATUS INFO 
BIC #WLS!DT!HSS,R1 ;REMOVE IRRELEVANT BITS 
BIT #DRDY, (R2) ;IS THE DRIVE READY? 
BEQ 10$ ;IF EQ NO 
CMP #HH!BH!ISLM,R1  ;HEADS, BRUSHES AND STATE OK? 
BEQ 208 ;IF EQ YES 
10S: BIT3 #US.SPU,U.STS(R5) ;IS DRIVE SPINNING UP? 
BNE DLPWF1 ;IF NE YES, WAIT FOR IT TO SPIN UP 
MOV #IE.DNR&377,RO ;SET RETURN ERROR CODE 
IMP DLFIN ;EXIT WITH FATAL ERROR 
208: BIC3 #US.SPU,U.STS(R5) ;RESET DRIVE SPINNING UP 
MOV I.PRM+10(R3),RO ;RETRIEVE STARTING DISK ADDRESS 
CAL DLDIFF ;CALCULATE DIFFERENCE WORD 
DLGO:  BEQ 30$ ;IF EQ NO SEEK IS NECESSARY 
MOV #SEEK,R1 GET CODE FOR SEEK FUNCTION 
CAL DLXCT ;EXECUTE THE SEEK 
BMI DLEROR ;IF MI ERROR DURING SEEK FUNCTION 
308: ADD #RLMP, R2 ;POINT TO RLMP 


SAMPLE DRIVER CODE 


MOV I.PRM+12(R3),R1 ;GET BYTE COUNT 

ROR Rl ;MAKE IT A WORD COUNT 

NEG Rl ;ALSO NEGATIVE 

MOV Rl, (R2) ; LOAD WORD COUNT 

MOV I. PRM+10(R3) ,-(R2) ;LOAD STARTING DISK ADDRESS 
MOV U.BUF+2(R5) ,-(R2) ;LOAD BUS ADDRESS 

CALL SBMSET ;SET I/O ACTIVE BIT IN MAP 

MOV U.BUF(R5),-(R2) ;;;LOAD FUNCTION AND GO 


; CANCEL I/O OPERATION IS A NOP FOR FILE STRUCTURED DEVICES. 
; 


DLCAN: RETURN 377NOP FOR RL11 


+ 


POWERFAIL IS HANDLED VIA THE DEVICE TIMEOUT FACILITY AND 
CAUSES NO IMMEDIATE ACTION ON THE UNIT. THE CURRENT TIMEOUT 
COUNT IS EXTENDED, THUS IF A UNIT WAS BUSY IT WILL HAVE 
SUFFICIENT TIME TO SPIN BACK UP. THE NEXT I/O REQUEST TO ANY 
UNIT WILL BE SUSPENDED FOR AT LEAST THE EXTENDED TIMEOUT UNLESS 
THE UNIT IS CURRENTLY READY. 


~e se "ee Se Ms NO TO Ne 


DLPWF: TSTB S.STS(R4) 7;IS DRIVE CURRENTLY BUSY? 
BEQ DLPWF2 ;IF EQ NO 
MOVB #4,S.STS(R4) ;ALLOW FOR A FULL MINUTE TO SPIN UP 
DLPWF1: MOVB #RLSPU,S.CTM(R4) ;EXTEND TIMEOUT INCASE UNIT WAS BUSY 
DLPWF2: BISB #US.SPU,U.STS(R5) ;SET UNIT SPINNING UP 
RETURN ; 
+ 


**-SDLINT-RL11-RLO1/02 DISK CONTROLLER 
INTERRUPT AND ERROR SERVICE ROUTINES 


me me MO we 


-ENABL LSB 


SDLINT::INTSV$ DL,PR5,RS$$L11 ;SAVE REGISTERS AND SET PRIORITY 


ae 
CALL SFORK +;;CREATE A SYSTEM PROCESS 
MOV R4,R3 ;COPY CONTROLLER INDEX 
ASRB RTTBL+1 (R3) ;HOME SEEK IN PROGRESS? 
BCS DLINIO ;IF CS YES 
MOV U.SCB(R5),R4 ;GET ADDRESS OF SCB 
MOV S.CSR(R4) ,R2 ;GET ADDRESS OF CSR 
MOV #IS.SUC&377,RO ;ASSUME SUCCESSFUL OPERATION 
MOV S.PKT(R4) ,R3 ;RETRIEVE I/O PACKET ADDRESS 
MOV (R2),R1 ;GET CONTENTS OF RLCS 
BMI 20$ ;IF MI AN ERROR OCCURRED 
SUB I. PRM+12(R3),U.CNT(R5) ;CALCULATE BYTES LEFT TO XFER 
BEQ 708 ;IF EQ NONE LEFT 
MOV U.CNT(R5),I.PRM+12(R3)  ;ASSUME LAST XFER COMING 
CMP U.CNT(R5),#RLBPT ;IS THIS THE LAST TRANSFER? 
BLOS 10$ ;IF LOS YES 
MOV #RLBPT,1I.PRM+12(R3)  ;TRANSFER A WHOLE TRACKS WORTH 
10$: BIC #CRDY,R1 ;CLEAR CRDY TO START FUNCTION 
MOV R1,U.BUF(RS) ;SAVE CURRENT FUNCTION AND ADDRESS BITS 
MOV RLBA(R2),U.BUF+2(R5) ;SAVE CURRENT BUS ADDRESS 
MOV I.PRM+10(R3),RO ;GET INITIAL DISK ADDRESS 
MOV RO,R1 ;COPY DISK ADDRESS 
BIS #77,RO0 ;UPDATE CYLINDER AND SURFACE ... 
INC RO ;... LEAVING SECTOR BITS ZERO 
MOV RO,1.PRM+10(R3) ;SAVE NEW DISK ADDRESS 
CALL DLDIFO ;CALCULATE MID-TRANSFER DIFFERENCE 
IMP DLGO ;GO DO THE OPERATION 
20S: BIT #DRDY,R1 ;IS THE DRIVE READY? 


BNE 
MOV3 
INC 3 
RETJIRN 


25S: 


DLEROR: MOV 
MOV 
BIT 
BNE 
BIT 
BEQ 
CALS 
BIT 
BEQ 
BIT 
BEQ 
MOV 
BR 

BIT 
BNE 
BIT 
BNE 
BIT 
BEQ 
MOV 
BR 


40S: 


BIT3 
BNE 
BIT3 
BEQ 
MOV 
BIT 
BEQ 
BIT 
BEQ 
MOV3 
MOV 
MUL 
ADD 
MOV 
MOV 
MOV 
MOV 
MOV 
BIC 
IMP 


80S: 


90S: 
DLFIN: 


MOV 
MOV 
MOV 
SUB 
MOV'3 
MOVI3 
BIS 
CAL. 
JMP 


+ 
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DLEROR 
#3,S.CTM(R4) 
U.CW2+1(R5) 


(R2),R1 
#IE.VER&377,R0 
#NXM,R1 

90$ 

#DE,R1 

40$ 

DLGST 

#WGE, RLMP (R2) 
90$ 
#WLS, RLMP (R2) 
DLRTRY 
#IE.WLK&377,R0 
DLFIN 
#10,U.BUF(R5) 
DLRTRY 

#OPI,R1 

DLRTRY 

#DCK,R1 

DLRTRY 
#IE.WCK&377,RO 
DLRTRY 


#IO.WLC&377,1.FCN(R3) 


80$ 


#US.WCK,U.STS(R5) 


DLFIN 
U.BUF(R5),R1 
#WCHK, R1 
DLFIN 

#10,R1 

DLFIN 
S.CON(R4),R1 


SAMPLE DRIVER CODE 


;IF NE YES, GO CHECK FOR ERRORS 
;WAIT 3 SECONDS FOR THE DRIVE TO SETTLE 
; FLAG SETTLE DOWN IN PROGRESS 


, 


;RETRIEVE CONTENTS OF RLCS 
; ASSUME UNRECOVERABLE ERROR 
;NON-EXISTENT MEMORY? 

:IF NE YES 

;DRIVE PROBLEMS? 

7; IF EQ NO 

;EXECUTE GET DRIVE STATUS FUNCTION 
;WRITE GATE ERROR? 

;IF EQ NO 

7;IS THE DRIVE WRITE LOCKED? 
;IF EQ NO 

;SET WRITE LOCK ERROR CODE 


’ 


;WRITE CHECK FUNCTION? 
;IF NE NO 

;OPERATION INCOMPLETE? 

;IF NE YES 

;WRITE CHECK ERROR? 

;IF EQ NO 

;YES, SET WRITE CHECK ERROR CODE 
;GO RETRY OPERATION IF REQUIRED 


;WRITE WITH WRITE CHECK? 
;IF NE YES 

;WRITE CHECK ENABLED? 

;IF EQ NO 

;GET CURRENT FUNCTION CODE 
s;WRITE OR WRITE CHECK FUNCTION? 
;IF EQ NO 

;WAS FUNCTION WRITE CHECK? 

;IF EQ YES 

;RETRIEVE CONTROLLER INDEX 


#RETRY,RTTBL(R1);RESET RETRY COUNT 


#5,R1 
#PRMSV,R1 


(R1}+,U.BUF(R5) 
(R1)+,U.BUF+2 (R5) 
(R1)+,U.CNT(R5) 
(R1)+,1.PRM+10(R3) 
(R1)+,1.PRM+12(R3) 


#10,U.BUF (RS) 
DLINIO 


; 
; FINISH I/‘) OPERATION 
; 


#IE.VER&377,RO0 
S.PKT(R4) ,R2 
1. PRM+4(R2),R1 
U.CNT(R5),R1 
S.CON(R4) ,R3 
RTTBL(R3) ,R2 


#RETRY*“D<256>,R2 


SIODON 
DLINI 


7FORM AN INDEX INTO SAVE AREA 
;RESTORE STARTING PARAMETERS 
pees 


. 
eee 


;CONVERT TO WRITE CHECK FUNCTION 
;START THE WRITE CHECK 


;SET UNSUCCESSFUL OPERATION 
;GET ADDRESS OF I/O PACKET 
;GET TOTAL TRANSFER SIZE 
;CALCULATE BYTES TRANSFERRED 
;RETRIEVE CONTROLLER INDEX 
;GET FINAL RETRY COUNT 

;MERGE STARTING RETRY COUNT 
;FINISH I/O OPERATION 

;PROCESS NEXT REQUEST 


**-DLOUT-RL11-RLO1/02 DISK CONTROLLER 
DEV -CE TIMEOUT ROUTINE 


DEVICE TIMEOUT RESULTS IN THE 
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DLOUT: MOV S.PKT(R4) ,R3 
BITB #US.SPU,U.STS(R5 
BEQ 20$ 
DECB S.STS(R4) 
BNE 10$ 
INCB S.STS(R4) 
BR 30$ 
10S: MTPS #0 
JMP DLINIO 
20S: TSTB U.CW2+1(R5) 
BEQ 30$ 
MTPS #0 
JMP DLEROR 
308: MTPS #0 
CALL DLRST 
MOV #IE.DNR&377,R0 
DLRTRY: MOV S.PKT(R4),R1 
BITB #I1Q.X,I.FCN(R1) 
BNE DLFIN 
DECB RTTBL(R3) 
BLE DLFIN 
JMP DLINIO 
+ 


INPUTS: 
Rl = FUNCTION CODE 
R2 = CSR ADDRESS 
R5 = UCB ADDRESS 
OUTPUTS: 


FUNCTION EXECUTED 
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SAMPLE DRIVER CODE 


OPERATION BEING REPEATED. 


TIMEOUTS ARE USUALLY CAUSED BY A POWER FAILURE BUT MAY ALSO 
BE THE RESULT OF A HARDWARE MALFUNCTION. 


;RETRIEVE I/O PACKET ADDRESS 
7;1S DRIVE SPINNING UP? 


=e 


I 
HAVE WE WAITED A MINUTE YET? 
NE NO 

LEAVE CONTROLLER BUSY 

LOG DEVICE TIMEOUT 

ALLOW INTERRUPTS 

TRY ENTIRE OPERATION 

IS DRIVE SETTLING DOWN? 

I 
Y 


ES, ALLOW INTERRUPTS 
OCESS THE ERROR 
;ALLOW INTERRUPTS 
;RESET DRIVE 
;SET DEVICE NOT READY 
;GET I/O PACKET ADDRESS 
; INHIBIT RETRIES? 


; 
; 
F 
; 
; 
E 
i 
7 
; 
R 


° 
a 
. 
’ 
I 
e 
a 
° 
7 
° 
’ 
R 
° 
a 
e 
f 
e 
, 
P 
e 
a 
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;IF NE YES 

;ANY MORE RETRIES LEFT? 

;IF LE NO 

;YES, RETRY ENTIRE OPERATION 


**-DLXCT, DLGST, DLRST-RL11-RL01/02 DISK CONTROLLER 
FUNCTION EXECUTION ROUTINES 


THIS ROUTINE WILL EXECUTE A GET DRIVE STATUS OR ANY 
NON-INTERRUPTABLE FUNCTION AND WAIT FOR ITS COMPLETION. 


Rl = CONTENTS OF RLCS (TESTED) 


;SET MESSAGE CODES IN RLDA 
;DO THE DRIVE RESET FIRST 

;SET MESSAGE CODES IN RLDA 
;SET GET STATUS FUNCTION 

;SAVE FUNCTION CODE 

;MERGE CURRENT DRIVE BITS 

;LOAD RLCS 

;READY OR ERROR? 

;IF EQ NEITHER 

;SAVE RLCS AND TEST FOR ERRORS 


~ENABL LSB 

DLRST: MOV #RST!STS!MRK, RLDA(R2) 
CALL 10$ 

DLGST: MOV #STS!MRK,RLDA(R2) 

10S: MOV #GSTS,R1 

DLXCT: MOV Rl,-(SP) 
MOVB U.UNIT(R5) ,1(SP)} 
MOV (SP)+,(R2) 

20S: BIT #ERR!CRDY, (R2) 
BEQ 20$ 
MOV (R2),R1 
RETURN ; 
-DSABL LSB 

+ 


THIS SUBROUTINE CALCULATES THE 
SEEK OPERATION. 


me Me Me Me TH TA TO Ne 


ISSUED. 


IF A HEADER CANNOT BE READ AFTER 16. 
AN ERROR WILL BE LOGGED AND A ONE CYLINDER REVERSE SEEK WILL BE 
THE SEEK IS FOLLOWED BY A READ HEADERS TO CAUSE AN 


**-DLDIFF-RL11-RLO1/02 DISK CONTROLLER 
CYLINDER ADDRESS DIFFERENCE CALCULATOR 


DIFFERENCE WORD USED IN THE 
RETRIES, 


INTERRUP". 


INPUTS: 
RO 
R3 


eo 


OUTPUTS: 
Rl = 
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DLDIFF: MOV 

10S: MOY’ 
CALL 
BPI. 
DEC 
BGT 
CMP 
CAI.L 
MOV 
MOV 
MOV 
CALL 
BM] 
BIC 
BI¢ 
MOVB 
MOVB 
MOV 


RETURN 


208: TST 
MOV 
DLDIFO: CLR 
BIC 
BIC 
CME 
BEC 
MOV 
BIC 
ASR 
ASR 
BIC 
BIC 
SUB 
BCC 
NEG 
BIS 
30S: INC 
BIS 
MOV 
MOV 


7+ 

a 

> INPUTS: 
: R2 
: R3 = 


‘ 


REGPAS: MOV 
MOV 


I. PRM+6 
IF EQ NO SEEK IS NECESSARY 


RETJRN 


DIFFERENCE WORD 
RLDA = LOADED WITH DIFFERENCE WORD 


SAMPLE DRIVER CODE 


DESIRED DISK ADDRESS 
I/O PACKET ADDRESS 


= LOADED WITH DIFFERENCE WORD 


#RETRY*2,-(SP) 
#RDH,R1 

DLXCT 

20$ 

(SP) 

10$ 
(SP) +, (SP) + 
DLRST 

#REV, RLDA(R2) 
#SEEK,R1 


#IE.VER&377,R0 


DLXCT 

DLFIN 

#377,R1 
#IE!RDH,R1 
#1,RTTBL+1 (R3) 


S.ITM(R4) ,S.CTM(R4) 


Rl, (R2) 


(SP) + 
RLMP(R2) ,R1 
I. PRM+6 (R3) 
#77,RO0 

477,R1 

RO,R1 

40S 

RO,-(SP) 
#*C<100>, (SP) 
(SP) 

(SP) 

#100,RO 
#100,R1 


(SP) +,Rl 
R1,RLDA(R2) 
Rl, 1. PRM+6(R3) 


CSR ADDRESS 
BUFFER ADDRESS 


(R2) ,(R3)+ 


RLBA(R2) ,(R3)+ 


;SET READ HEADER RETRY COUNT 

;SET CODE FOR READ HEADERS FUNCTION 
;EXECUTE THE FUNCTION 

;IF PL FUNCTION EXECUTED OK 

ANY RETRIES LEFT? 

PEP Gt YES 

;REMOVE RETRY COUNT AND CALLERS ADDRESS 
;RESET DRIVE 

; LOAD REVERSE SEEK DIFFERENCE WORD 
;GET CODE FOR SEEK FUNCTION 

; ASSUME WE WILL FAIL 

;EXECUTE THE SEEK 

7;IF MI WE FAILED 

;CLEAR OUT FUNCTION BITS 

;LOAD CODES FOR READ HEADER 

; INDICATE REVERSE SEEK IN PROGRESS 
SET DEVICE TIMEOUT COUNTER 

; LOAD FUNCTION AND GO 

;WAIT FOR THE INTERRUPT 

;REMOVE RETRY COUNT 

;RETRIEVE HEADER WORD 

;RESET DIFFERENCE WORD 

;MASK OUT SECTOR BITS 

;DO WE NEED TO DO A SEEK? 

;IF EQ NO 

;SAVE DESIRED DISK ADDRESS 

7; ISOLATE SURFACE BIT 

;PUT INTO THE PROPER POSITION 
;REMOVE SURFACE BIT 

feee 

;SUBTRACT DESIRED FROM ACTUAL 

;IF CC ACTUAL >= DESIRED 

;ACTUAL < DESIRED, MAKE POSITIVE DIFFERENCE 
;SET SIGN FOR MOVE TO CENTER OF DISK 
;SET MARKER BIT 

;MERGE IN SURFACE BIT 

; LOAD DIFFERENCE WORD 

;SAVE DIFFERENCE WORD 


e 
td 


MOVE THE *ONTROLLER/DRIVE REGISTERS INTO THE SPECIFIED BUFFER. 


;MOVE RLCS 
s;MOVE RLBA 


SAMPLE DRIVER CODE 


MOV RLDA(R2),(R3)+  ;MOVE RLDA 
MOV RLMP(R2),(R3)+ ;MOVE RLMP 

CLR (R3)+ ;CLEAR PLACE HOLDERS... 

CLR (R3)+ ;...SO HRC/CON WILL WORK 

CALL DLGST ;EXECUTE GET DRIVE STATUS FUNCTION 
MOV RLMP(R2) , (R3) ;SAVE DRIVE STATUS 

RETURN ; 


+ 


**-DLKRB-CONTROLLER ON-LINE/OFF-LINE ROUTINE 


THIS ROUTINE WILL HANDLE RECONFIGURATION CALLS FOR ON-LINE 
CONTROLLER AND OFF-LINE CONTROLLER FOR THE RL11. 


INPUTS: 
R2 = KRB ADDRESS 
R3 = CTB ADDRESS 
C=] IF OFF-LINE REQUEST 
C=0 IF ON-LINE REQUEST 


me Me Me Me Me Me Ne Ne Me Ne Ne Ne Me Ne we 


OUTPUTS: 
NONE 
DLKRB: BCS DLOFL ;HANDLE OFF-LINE REQUEST 


CODE SPECIFIC TO HANDLE THE CONTROLLER COMING ON-LINE. 


é™e we Se 


RETURN ;EXIT 


CODE SPECIFIC TO HANDLE THE CONTROLLER GOING OFF-LINE 


me Me Me 


DLOFL: 
RETURN 


me me 


+ 


**-DLUCB-UNIT ON-LINE/OFF~LINE ROUTINES 


THIS ROUTINE WILL HANDLE RECONFIGURATION CALLS FOR ON-LINE 
UNIT AND OFF-LINE UNIT FOR RLO1 AND RLO2 DRIVES. 


INPUTS: 
R3 = CONTROLLER INDEX 
R4 = SCB ADDRESS 
R5 = UCB ADDRESS 


C=1 IF OFF-LINE REQUEST 
C=0 IF ON-LINE REQUEST 


me Me MB Me Te Ne Me Me NE MO Te TO MO Me TO TO 


OUTPUTS: 
NONE 
DLUCB: BCS DLOFLU ;IF CS OFF-LINE REQUEST 
SPECIFIC TO BRINGING UNIT ON-LINE. 


QO 
[o) 
1w) 
ie) 


RETURN 


=e 


; CODE SPECIFIC TO TAKING UNIT OFF-LINE. 


SAMPLE DRIVER CODE 


. 
f 


DLOFLU: i 
RETURN ; 


- END 


8.3 HANDLING SPECIAL USER BUFFERS 


Some drivers need to handle user buffers in addition to the buffer 
that the Executive address-checks and relocates in a normal transfer 
request. Address-checking and relocation operations must take place 
in the context of the task issuing the I/O request, because the 
mapping registers are set for the issuing task. However, ii che 
normal driver interface, the task context after the call to $GTPKT is 
not, in general, that of the issuing task. 


Thus, drivers that need to handle special buffers must be able to 
refer to the I/O packet before it is queued, while the context of the 
issuing task is still intact. 


The coding shown in this section is an excerpt from a driver. that 
illustrates the handling of a special user buffer. The key points 
are: 


1. The UC.QUE bit has been set in the control byte (U.CTL) of 
the UCB for each device/unit. 


2. The routine (ZZINI) that is defined as the I/O initiation 
entry point in the driver dispatch table (DDT$) macro call 
oerforms the following actions: 


a. Retrieves the user virtual address and address-checks it 


9. Relocates the virtual address and stores the result back 
into the packet 


2. Inserts the packet into the I/0 queue and continues 
execution inline to the entry point BMINI, which calls 
SGTPKT 


3. The driver propagates its own execution by branching back to 
BMINI to call S$GTPKT. 


-TITLE BMTAB - DATA BASE FOR BLOCK MOVE DRIVER 
-IDENT /01/ 


COPYRIGHT (c) 1981, 1982 BY 
DIGITAL EQUIPMENT CORPORATION, MAYNARD 
MASSACHUSETTS. ALL RIGHTS RESERVED. 


me me Me te MO Ne 


THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED 
AND COPIED ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE 
AND WITH THE INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS 
SOFTWARE OR ANY OTHER COPIES THEREOF, MAY NOT BE PROVIDED OR 
OTHERWISE MADE AVAILABLE TO ANY OTHER PERSON. NO TITLE TO AND 
OWNERSHIP OF THE SOFTWARE IS HEREBY TRANSFERRED, 


THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT 
NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL 
EQUIPMENT CORPORATION, 


bt a el eT Bt el eT eT eT | 


SAMPLE DRIVER CODE 


DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF 
ITS SOFTWARE ON EQUIPMENT THAT IS NOT SUPPLIED BY DIGITAL. 


LOADABLE DATA BASE FOR EXAMPLE BUFFERED I/O DRIVER 


MACRO LIBRARY CALLS 


me “Te M6 “8 MO MO we TH Ne Be Be We 


-MCALL CLKDFS 
-MCALL HWDDFS 
-MCALL SCBDFS$ 
-MCALL UCBDFS 


CLKDFS ;DEFINE CLOCK BLOCK OFFSETS 
HWDDFS$ ; DEFINE HARDWARE REGISTERS 
SCBDFS ry OYSDEF ;DEFINE SCB OFFSETS 
UCBDFS ;DEFINE UCB OFFSETS 
SBMDAT:: 
’ 
; BM DCB 
; 
SBMTBL=0 ; LOADABLE BMDRV 
SBMDCB:: 
»WORD 0 3; D.~LNK 
»WORD - BMO ; D.UCB 
»ASCII /BM/ ; D.NAM 
»WORD BMND-BMST ; D.UCBL 
»WORD SBMTBL ; D.DSP 
; D.MSK - FUNCTION MASKS 
» WORD 33 ; LEGAL 0-17 IO.KIL,IO.WLB,IO.ATT 
; I0.DET 
»WORD 31 ; CONTROL 0-17 IO.KIL,IO.ATT,IO.DET 
»WORD 0 ; NOOP 0-17 
»WORD 0 ; ACP 0-17 
»WORD 4 3; LEGAL 20-37 IO.WVB 
»WORD 0 3; CONTROL 20-37 
»WORD 0 3; NOOP 20-37 
»WORD 0 ; ACP 20-37 
»WORD 0 ; D.~PCB 
: BM UCB'S 
PRO=0 
BMST=. 
IF DF MSSMUP 
e~WORD 0 
e ENDC 
~BMO:: 
«WORD SBMDCB U.DCB 
~WORD 2-2 U.RED 


-BYTE UC.QUE,0 
- BYTE 0,US.OFL 
-WORD DV. REC 


U.CTL,U.STS 
U.UNIT,U.ST2 
U.CWl 


me Me MO Me we 
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SAMPLE DRIVER CODE 


-WORD 0 ; U.CW2 
.WORD 0 ; U.CW3 
-WORD 72. ; U.CW4 
-WORD SBMO ; U.SCB 
.WORD 0 ; U.ATT 
-WORD 0,0 ; U.BUF,U.BUF+2 
.WORD 0 ; U.CNT 
BMND=. 
: BM SCB'S 
SBMO:: .WORD 0,.-2 ; S.LHD 
.WORD 0,0,0,0 ; S.FRK 
.WORD 0 ; S.KS5 
,WORD 0 ; S.PKT 
.BYTE 0,0 ; S.CTM,S.ITM 
.BYTE 0,0 ; S.STS,S.ST3 
.WORD 0 ; S.ST2 
.WORD 0 ; S.KRB - NO KRB SINCE NO CONTROLLER 
SBMEND:: 
. END 
.TITLE BMDRV - BLOCK MOVE DRIVER 
-IDENT /01/ 
+ 


COPYRIGHT (c) 1981,1982 BY DIGITAL EQUIPMENT CORPORATION. 
ALL RIGHTS RESERVED. 


™e me Me MO ON 


THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED 
OR COP"“ED ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE. 


THIS IS A SAMPLE DRIVER WHICH DEMONSTRATES HOW TO USE SOME 
OF THE MORE SOPHISTICATED EXECUTIVE SERVICES AVAILABLE TO 
71/0 DRIVERS. THIS DRIVER DEMONSTRATES: 


we me ™e MO Ne Me Se MO MO 


-.) THE CHECKING OF ADDITIONAL USER BUFFERS PRIOR TO QUEUEING 
AN I/O PACKET. 


?”) USE OF THE CLOCK QUEUE FROM A DRIVER. 
“) USE OF THE BUFFERED I/O MECHANISM 


£) USE OF THE GENERAL BUFFEéRED I/O KERNEL AST MECHANISM 


me Me me Me NO Ne Me Ne Me Me NS 


©) USE OF REGION LOAD KERNEL ASTS 


€) USE OF BLXIO 


THIS DRIVER UNDERSTANDS PRECISELY ONE QIO, WHICH IS: 


eee IO.WLB,.....,<DEST~BUFFER, LENGTH, TIME, SRC-BUFFER> 
OR 
IO.WVB 


dt et ed et et et TY 


THE DRIVER QUEUES A CLOCK BLOCK FOR TIME TICKS AND AT THE 
END OF THAT TIME INTERVAL COPIES THE SOURCE BUFFER TO THE 


me te Me 
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m™e Me te 


=e we 8 


DESTINATION BUFFER. 


SAMPLE DRIVER CODE 


IF POSSIBLE, THE REQUEST IS BUFFERED 


INTERNALLY WHILE THE CLOCK REQUEST IS POSTED. 


~-MCALL CLKDFS$, PKTDFS 
CLKDFS$ ;DEFINE CLOCK BLOCK OFFSETS 
PKTDFS$ ;DEFINE I/O PACKET OFFSETS 


DEFINE MAXIMUM TRANSFER 


BUFLIM = 


DDTS 


+ 


**k — BMINI 


INPUTS: 


100. 


LENGTH WHICH WILL BE BUFFERED 


BM, ,NONE,, ,NEW 


- I/O INITIATION ENTRY POINT 


DRQOITO (BECAUSE THE UC.QUE BIT IS SET IN THE UCB) SETS THE 
REGISTERS TO THE FOLLOWING: 


Rl 
R4 
RS 
OUTPUTS: 


LE 


Woil 


ADDRESS OF I/0 PACKET 
ADDRESS OF SCB 
ADDRESS OF UCB 


THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT- 


se Ne te Ne Ne Ne Me Ne we Ne Ne Ne Ne Ne te Me Ne Ne Ne Ne Me MO MH Me NO MO ws Ne NO Me Me Me Me MO MO MO MO TO Ne we NO Ne 


ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/0 OPER- 
ATION IS INITIATED. 


I/O REQUEST PACKET FORMAT: 


I.LNK -- I/O QUEUE THREAD WORD. 

I.PRI/I.EFN -- REQUEST PRIORITY, EVENT FLAG NUMBER. 

I.TCB -- ADDRESS OF THE TCB OF THE REQUESTER TASK. 

I.LN2 -- POINTER TO SECOND LUN WORD IN REQUESTER TASK HEADER. 

I.UCB -- UCB ADDRESS OF DEVICE 

I. FCN -- I/O FUNCTION CODE (IO.WLB). 

I.IOSB -- VIRTUAL ADDRESS OF I/O STATUS BLOCK. 

I.IOSB+2 -- RELOCATION BIAS OF I/O STATUS BLOCK. 

I. 10SB+4 -- I/O STATUS BLOCK ADDRESS (DISPLACEMENT + 140000). 

I. I0SB+6 -- VIRTUAL ADDRESS OF AST SERVICE ROUTINE. 

I. PRM -- RELOCATION BIAS OF SOURCE BUFFER. 

I. PRM+2 -- BUFFER ADDRESS OF I/0 TRANSFER. 

I. PRM+4 -- NUMBER OF BYTES TO BE TRANSFERED. 

I. PRM+6 -- TIME DISPLACEMENT IN TICKS 

I. PRM+10 -- VIRTUAL ADDRES (TO BECOME RELOCATION BIAS) OF 
DESTINATION BUFFER 

I. PRM+12 -- FILLED IN WITH DISPLACEMENT ADDRESS OF DESTINATION 
BUFFER 

I. PRM+14 -- USED TO STORE BUFFER/CLOCK BLOCK ADDRESS 

I. PRM+16 -- FILLED IN WITH PCB ADDRESS OF OUTPUT BUFFER 

-ENABL LSB 


AT et et ee TY 


BMINI: 


me “ee Se Te MO MO Me WO TE He MO ME TO ME MH MO He MO Te Me me te Me Me Me TO Me 
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SAMPLE DRIVER CODE 


HEE KKKKEREKKEKREKEEKREKRKEKKEKEKEKEKREKRKEEKRKEKEKKEKRKKEKKKRKKKRKKKKRKRKKK KKK 


* * 
as INITIATION ENTRY POINT * 
* & 


HHKKKKKKKKE KKK KEKE KKK KEKE KEK RRR EKER RERKKKEKKKEKKKKKKKKKKKKK 


; PRE-QUEUING INITIALIZE ENTRY POINT 


KHKKEKKEKRKEKEKKEKEKEKKEREKERERKKKKEEKKKKKEKRERKKKEKKKKRKKKRKRKEKKKKKKKKR KK KKK 


6 * 
* ADDRESS CHECK THE SOURCE BUFFER WHILE THE TASKS * 
* CONTEXT IS LOADED, AND FILL IN THE NECESSARY * 
~ PARAMETERS IN THE I/0 PACKET * 
* * 
HK KIKKKKKKKKKEKKKKEKEKEKKEKEKKEEKEKEEKEKKKEKKKKKKKKEKKKKKKKKKKRKKRKKKR RAK 


MOV R1,R3 ; COPY ADDRESS OF I/O PACKET 
MOV I.PRM+10(R1),RO ; GET VIRTUAL ADDRESS OF SOURCE BUFFER 
MOV I.PRM+4(R3),R1 ; AND LENGTH OF SOURCE BUFFER 


| THE INPUT PARAMETERS FOR SCKBFR ARE: 


| 
RO = STARTING ADDRESS OF BLOCK TO BE CHECKED 
| Rl = LENGTH OF THE BLOCK TO BE CHECKED 
| SATTPT = ADDRESS OF I.AADA IN I/O PACKET 
| (ESTABLISHED IN DRQIO) 
CURRENT TASK HEADER MUST BE MAPPED THROUGH APR 6 
(ESTABLISHED BY DIRECTIVE DISPATCHER) 


THE OUTPUT PARAMETERS ARE: 


| 
| 
| 
| I.AADA OR I.AADA IN PACKET POINTS TO 
| 
| 
| 


C = 0 IF CHECK AND PACKET UPDATE SUCCESSFUL 
RELATED ADB, P.IOC, A.IOC INCREMENTED 
C = 1 IF CHECK UNSUCCESFUL OR I.AADA, I.AADA 
ALREADY FILLED IN 
fee ewoo mee Sense ese aa eee eee See eee ee + 
CALL SCKBFR ; CHECK BUFFER, INCREMENT A.IOC AND 
; P.IOC FOR APPROPRIATE REGIONS 
3CC 10$ ; IF CC ALL WAS OK 
KKK KKEKIKKKKKKEKKEKKEEKKKKKKKKKKKKKKKKAKKKKKKKRKRKKRKRKRKRKKKKKKRKRKKKRKKEKE 
k * 
k SOURCE BUFFER WAS ILLEGAL, FINISH I/O HERE * 
* * 


REKKEKEKKKKEKEKEKEEKKEKEKKKKEKKKEEKKKRKEKEKEKRREKKKKRKKKKKKKKRKKKKKRKKKRKKKKRKREKEK 


ET COMPLETION STATUS 


MOV #IE.SPC&377,RO ; S 
; AND NUMBER OF BYTES TRANSFERRED 


CLR Rl 


me te Me Ne M8 Me MSO MO MO MO We NS NS 


me MO Me BO Te TO 


me Te MO MH we NO TE NO MO TE Me TO 


10$: 
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SAMPLE DRIVER CODE 


THE INPUT PARAMETERS FOR SIOFIN ARE: 


RO = FIRST WORD OF I/O STATUS TO RETURN 
Rl = SECOND WORD OF I/O STATUS TO RETURN 


THE OUTPUT PARAMETERS ARE: 


| 
| 
| 
| 
| 
ADDRESS OF I/O PACKET 
| 
| 
| 
R4 IS DESTROYED l 

| 


| 
| 
| 
| 
| 
| R3 
| 
| 
| 
| 
| 


$a = 5 ee ee ee ee e+ + 
CALLR SIOFIN ; COMPLETE I/O AND EXIT DRIVER 

WHRKKKEKKEKEKEKEKEKEKKEEKKEEKEEKKEEKEKKEREEKKEEKKKEKKEKKKEKKRKKKKRKKKK KR KKK 
* * 
* BUFFER WAS LEGAL, CONVERT VIRTUAL ADDRESS TO * 
: ADDRESS DOUBLEWORD AND STORE PARAMETERS : 


WHKKEAKKKEKKEKKKHKEKKHERKKHKRRAKKERKKKRKKRKKKKKKKKKKKRKRKKKKKKKKKKKKKRKRKKKKRKEK 


THE INPUT PARAMETERS FOR SRELOC ARE: 
RO = USER VIRTUAL ADDRESS TO RELOCATE 


| 
| 
| 
| 
| THE OUTPUT PARAMETERS ARE: 
| 
| 
| 
| 


Rl = APR6 RELOCATION BIAS OF USER BUFFER 
R2 = DISPLACEMENT IN BLOCK + 140000 
4---------------~---------- ~~ -- - -- - - 5 - + + - +--+ = = + +--+ + 
CALL $RELOC ; RELOCATE BUFFER ADDRESS 
MOV R1,I.PRM+10(R3) ; SAVE APR BIAS OF SOURCE BUFFER 
MOV R2,I.PRM+12(R3) ; AND DISPLACEMENT ADDRESS 
CLR I. PRM+16(R3) ; INDICATE NOT BUFFERED I/O 
RARKEKKEKKEKEEKEKEKEKERERKKKKREKEEKRKKKKKKRKKKEKRKKKK RK KKK KKK KKK KRK 
* * 
* NOW QUEUE THE PACKET IN THE DEVICE QUEUE * 


KRREKKKEKEKEKREKKEKEKEKEREKREREKKEEKERKEKEEKEKEKRKEKKEKEKEKKKKKKKKKRKKKKRK KKK 


MOV R4,R0 ; COPY POINTER TO I/O QUEUE LISTHEAD 
MOV R3,R1 ; AND ADDRESS OF I/0 PACKET 
$-------~-------+-- +--+ - + - - = +--+ +--+ + + + + + 


THE INPUT PARAMETERS FOR SQINSP ARE: 


ADDRESS OF THE TWO WORD LISTHEAD 


| 

| 

| 

RO | 
ADDRESS OF THE PACKET TO BE INSERTED | 
| 

| 

| 


| 
| 
| 
| Rl 
| 
| 
| 


NO OUTPUT PARAMETERS 


CALL SQINSP ; INSERT PACKET IN QUEUE 


me Te SNe SO Ne 


=e Se Se ™8 MO 


™e we Se 


me se TO 


=e me Me Ne Ne Me 


‘BMINI: 
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SAMPLE DRIVER CODE 


REKKEKKEKEKEK KK EKKKEKRREKEKEKKK EKER REREREREKKKRKEKRKKKKKRKKRKRKRKKKRKEKRKKK 


x * 
*- BEGIN SERIAL PROCESSING OF I/O PACKETS * 
k * 


KUKI KKEKEKEKEKEKKEKEEKEEKEKEKEKHKHKKKKKKEKRKKKKKKKKKKKRKKKKKKKKKKRKKEKEK 


THE INPUT PARAMETERS FOR SGTPKT ARE: 
R5 = ADDRESS OF THE UCB OF REQUESTING UNIT 
THE OUTPUT PARAMETERS ARE: 


| 
| | 
| 
| 
| | 
| | 
| | 
| Cc O IF A REQUEST WAS SUCCESSFULLY DEQUEUED | 
| | 
| | 
| | 
| 
| | 
| | 
| | 


Rl = ADDRESS OF THE I/O PACKET 
R2 = PHYSICAL UNIT NUMBER 
R3 = CONTROLLER INDEX 
R4 = SCB ADDRESS OF CONTROLLER 
R5 = UCB ADDRESS OF UNIT 
C = 1 IF UNIT BUSY OR NO PACKETS QUEUED 
fen -----~- + +--+ + ee ee ee ee = + 
CALL SGTPKT ATTEMPT TO GET A REQUEST 
3CC 20$ IF CC WE GOT ONE 


me Oe MO 


DEVICE BUSY OR QUEUE EMPTY 


; REFERENCE LABEL 
KEKE KKKEEKEKR KKK KEKE KKK 
* 


RETURN 


k 


x ATTEMPT TO ALLOCATE CLOCK BLOCK i 
x * 


REKKKKKKKEKEKEKEKEEEREEKKEKKKEKKKEKERREKEKRKREKKEKEKERKRRKKEKRKEKRKKKKEKRKKKRKKKK 


MOV R1,R3 ; COPY I/O PACKET ADDRESS 
MOV #C.LGTH,R1 ; SET LENGTH OF CLOCK BLOCK 
fo~--- ~~~ + +--+ + + + ee + + 


THE INPUT PARAMETERS FOR SALOCB ARE: 
Rl = SIZE OF THE BLOCK TO ALLOCATE (IN BYTES) 


THE OUTPUT PARAMETERS ARE: 


C = 0 IF A BLOCK WAS SUCCESSFULLY ALLOCATED 
RO = ADDRESS OF THE ALLOCATED BLOCK 
Rl = LENGTH OF THE ALLOCATED BLOCK 
C = 1 IF NO BLOCK ISCURRENTLY AVAILABLE 
$---------------- +--+ +--+ 5 5 - = = = = = + 
SREL SALOCB ; ATTEMPT TO ALLOCATE 
3CC 30$ ; IF CC SUCCESSFUL 
MOV #IE.NOD&377,RO ; SET I/O STATUS 


~™~e we MO MO ME MSH MO MS TO WS 6M MA MO MS OMe 


30S: 


=e ™e Ne Ge BO 
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SAMPLE DRIVER CODE 


THE INPUT PARAMETERS FOR SIOALT ARE: 


RO = FIRST WORD OF I/O STATUS BLOCK 
Rl = SECOND WORD OF I/0 STATUS BLOCK 
R2 = STARTING AND FINAL RETRY COUNTS 
R5 = UCB ADDRESS OF UNIT TO COMPLETE 


THE OUTPUT PARAMETERS ARE: 


| | 
| | 
| | 
| | 
| | 
| | 
| (IF AN ERROR LOGGING DEVICE) | 
| | 
| | 
| | 
| | 
| R4 IS DESTROYED | 
| | 


fon nn + +--+ + 
CALL SIOALT ; AND COMPLETE THE I/O 

BR BMIN1 ; GO LOOK FOR MORE WORK 

MOV RO,I.PRM+14(R3) ; SAVE ADDRESS OF CLOCK BLOCK 
KRREKKEKKEKEKEKREKEKKEEKEKKEKKEKKKKEKRKKKRKRKKRKKKKRKKKKKKKRKRKKKRKKKRKRKKKKKRKR KKK 
* * 
* DETERMINE IF I/O REQUEST IS BUFFERABLE * 
& * 


REEKKKEKEKEKKEEKKKKKKKKKKKKKKKKKKKKKKRKKKKKKKKKKKKKKKKKKKKKRKKKKKKRKEKK 


THE INPUT PARAMETERS FOR STSTBF ARE: 
R3 = ADDRESS OF I/O PACKET TO TEST 


THE OUTPUT PARAMETERS ARE: 


C = 0 IF REQUEST MAY BE BUFFERED 

C = 1 IF REQUEST MAY NOT BE BUFFERED 
$o— +--+ ee ee ee + + 
CALL STSTBF ; TEST FOR BUFFERABLE I/0 REQUEST 
BCS 40$ ; IF CS CAN'T ALLOCATE A BUFFER 
KRHAKKEKREKKKKEKKKKKKKKKREKKEREKKKKKRRKRKKKK KKK KKK RRR KKK KKK KKK KEK 
* k 
* ATTEMPT TO ALLOCATE A BUFFER * 
* * 


KRREKKKKHEKKEEKKE KEKE KEKE KEKE EEKEKEKKEKEKRKKEKKKKKKRKKKKRKK 


MOV I.PRM+4(R3),R1 ; GET LENGTH OF BUFFER 
CMP R1l,#BUFLIM ; BIGGER THAN BUFFER LIMIT ? 
BHI 40$ ; IF HI YES, DON'T BUFFER 


i il it eT i ent ee eT et eT eT eT TY 


me me Me MO Owe 
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me Me Me Ne 
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SAMPLE DRIVER CODE 


THE INPUT PARAMETERS FOR SALOCB ARE: 


Rl = SIZE OF THE BLOCK TO ALLOCATE (IN BYTES) 


| 
| 
| 
| 
THE OUTPUT PARAMETERS ARE: | 
| 
| 
| 
| 


C = 0 IF A BLOCK WAS SUCCESSFULLY ALLOCATED 
RO = ADDRESS OF THE ALLOCATED BLOCK 
Rl = LENGTH OF THE ALLOCATED BLOCK 
C = ] IF NO BLOCK ISCURRENTLY AVAILABLE 
pee eee eee + ee oo  -  - - - - == + 
CALL SALOCB ; TRY TO ALLOCATE BUFFER 
BCS 40$ ; IF CS COULDN'T GET ONE 


WKH KEREKKKEKEKEKKKREKKRKEKKEKEEKKKEKKEKKKEKKKKEKRKRKRKKKKKRKKKKRKKKKRKRKRKKKKKEKK 
the * 
x COPY USER BUFFER TO INTERNAL BUFFER * 


* * 
SHKKKEKKEKKEKKEEKEKKEKEKKKKEKKEKKKEKKKKEKKKKKKKKKKKKKRKKKKRKKKKKKKKKKRKR KKK 


MOV RO,R4 ; SET ADDRESS OF DESTINATION BUFFER 
MOV R3,R5 ; SAVE ADDRESS OF I/O PACKET 

MOV I.PRM+4(R5),RO ; SET LENGTH OF TRANSFER 

MOV I.PRM+10(R5),R1l ; SET BIAS OF SOURCE BUFFER 

MOV I.PRM+12(R5),R2 ; AND DISPLACEMENT 

BIC #140000, R2 ; STRIP OFF APR6 ADDRESS BITS 

BIS #120000, R2 ; AND SUBSTITUTE APR5 

MOV R4,I.PRM+10(R5) ; SET INTERNAL BUFFER ADDRESS INTO PACKET 
ec ee ec cw ee ce ec es ee ee re ee ee ee es ce es ees es ee we ee es ee ee ee ee ee ee ee ee ee ee ee ee re ee ee + 
| | 
THE INPUT PARAMETERS FOR S$BLXIO ARE: | 
| 
RO = NUMBER OF BYTES TO MOVE | 
| Rl = SOURCE APR 5 BIAS | 
| R2 = SOURCE DISPLACEMENT | 
| R3 = DESTINATION APR6 BIAS | 
| R4 = DESTINATION DISPLACEMENT | 
| | 
| THE OUTPUT PARAMETERS ARE | 
| | 
| RO ALTERED | 
| R1l,R3 PRESERVED | 
| R2,R4 POINT TO LAST BYTE OF SOURCE/DESTINATION +1 | 
| 
4+ ---~--------~---~----------- - -- -- - - - - - - - - - - + 


CALL SBLXIO ; COPY TO INTERNAL BUFFER 
KKK KKK IK KK IKK IKK KKK KIKI RARE ERE KE EKREREKRKEAEREKE 
* * 


il CONVERT TO BUFFERED I/O REQUEST = 
* * 


RREKEKKKEEKEKKEKREKRKEKEKEKREKKEKEKKEEKRKEKREKRKEKEEKEKRKEKEKKEEKKKRKEKKKKKKKRKKRKKRKKEK 


MOV R5,R3 ; COPY I/0 PACKET ADDRESS BACK 


=e “e "6 te TO MO MO MO NS 
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CLKSRV: 
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SAMPLE DRIVER CODE 


THE INPUT PARAMETERS FOR SINIBF ARE: 


| 
R3 = ADDRESS OF THE I/O PACKET TO BUFFER | 
| 
NO OUTPUT PARAMETERS. | 

| 


pon n---- +--+ +--+ + 
CALL SINIBF ; INITIALIZE BUFFERED I/0 
HRREKKEKEKEEKKKEEKEKKEKEKKRKEKRKEKKEKKKERKKKKEKKKKKKKRKKKKKRKK KKK KKK RR 
* * 
* QUEUE THE CLOCK BLOCK : 
* 


HREEKKKEKEEKEKKEKEKKEKKKEKEEKEKEKKRRKEKRRKEKKKKKKKKKKKRRKRKKKKKRKRKRKKKK KKK KKK 


NO OUTPUT PARAMETERS. 


MOV I.PRM+14(R3),RO ; GET ADDRESS OF CLOCK BLOCK 

MOV #CLKSRV,C.SUB(RO) ; SET ADDRESS OF SUBROUTINE 

CLR Rl ; HIGH ORDER DELTA TIME 

MOV I.PRM+6(R3),R2  ; LOW ORDER PART 

MOV #C.SYST,R4 ; SET REQUEST TYPE 

MOV R3,R5 ; USE PACKET ADDRESS AS IDENTIFIER 
4+----+--------------------- --- --- - - - - - - - - + - - - - ee + 
| | 
| THE INPUT PARAMETERS FOR SCLINS ARE: | 
| | 
| RO = ADDRESS OF THE CLOCK BLOCK TO QUEUE | 
| Rl = HIGH ORDER HALF OF DELTA TIME | 
| R2 = LOW ORDER HALF OF DELTA TIME | 
| R4 = REQUEST TYPE | 
R5 = ADDRESS OF REQUESTING TASK OR IDENTIFIER | 
| | 
| 
| 


CALLR SCLINS ; QUEUE CLOCK BLOCK AND TEMPORARILY 
; EXIT THE DRIVER 


UHKKEKKKKKEKKEKRKEKEEERERKERERRKKEKRKKRKKEKRKEKRKKKKRKRKRKRKK KKK KKKKKKRKKRKRRKKKEK 
* * 
* CLOCK ENTRY POINT * 
* * 
HHEAEKKKKKKKKKEKKKKKKKKKKKKKRKKKKKKRKKRKKKK KKK KKK KKK RK 


UAEAKKKKKKKKKKKKKRKKKRKKKKKKKKRKKRKRKKRKKRKKRRKKKKKKRKRKKRKKKKKKKAKKKRKRKKKKKRKRKEK 


te * 
* CHECK TO SEE IF THE I/O WAS BUFFERED x 
oF * 


HHKEEKKKEKEKKEKEKEKKEKREK IKK KKK EKRKREKREKRKKKKEKKRKKKKKRKRKKKKKKKKKKRKKKKK 


MOV C.TCB(R4),R5 ; GET ADDRESS OF I/O PACKET 

TST I. PRM+16(R5) ; WAS IT BUFFERED I/0 

BNE 50$ ; IF NE YES, GO QUEUE KERNEL AST 

HR KKK KEKE KIRK RK IIR ERE IRIE ARERR RRR ERR EEK KERIKERI REE RK KEK KES 
te x 
ba COULDN'T BUFFER, PERFORM COPY HERE AND NOW i 
# * 


HRKEKKEKKEEKKKEKEEKEKEKKEKEKRKRERKRKEKKRKERKKKKKKKRKRKKKKRKKRKKKRKKKKRKRKKKRKKEKK 


me Se MO Ne 


me Se M8 we Ne Ne 


=e ™e Se Me Me OM 


me 


Tt eT eT Pe a 


SAMPLE DRIVER CODE 


MOV I.PRM+4(R5),RO ; SET LENGTH TO TRANSFER 

MOV I.PRM+10(R5),R1 ; BIAS OF SOURCE BUFFER 

MOV I.PRM+12(R5),R2 ; DISPLEACEMENT OF SOURCE 

ELC #140000,R2 ; STRIP OFF APR6 ADDRESS BITS 
ie Re #120000, R2 ; AND CONVERT TO APR5 

MOV I.PRM(R5) ,R3 ; SET BIAS OF DESTINATION 
MOV I.PRM+2(R5),R4 3; SET DISPLACEMENT 


THE INPUT PARAMETERS FOR SBLXIO ARE: 


RO = NUMBER OF BYTES TO MOVE 
Rl = SOURCE APR 5 BIAS 

R2 = SOURCE DISPLACEMENT 

R3 = DESTINATION APR6 BIAS 

R4 = DESTINATION DISPLACEMENT 


THE OUTPUT PARAMETERS ARE 
RO ALTERED 


R1,R3 PRESERVED 
R2,R4 POINT TO LAST BYTE OF SOURCE/DESTINATION +1 


CALL SBLXIO ; COPY BUFFER 
MOV IT.PRM+14(R5),RO ; GET ADDRESS OF CLOCK BLOCK 
MOV #C.LGTH,R1 ; GET LENGTH OF CLOCK BLOCK 


THE INPUT PARAMETERS FOR SDEACB ARE: 


ADDRESS OF BLOCK TO DEALLOCATE 
LENGTH OF BLOCK TO DEALLOCATE 


RO 
Rl 


NO OUTPUT PARAMETERS. 


fee ee ee ee ee ee ee ee eS 
CALL SDEACB ; DEALLOCATE IT 

MOV R5,R3 ; COPY PACKET ADDRESS FOR S$IODON 

MOV #IS.SUC&377,RO ; SET FINAL I/O STATUS 

MOV I.PRM+4(R3),R1 ; AND LENGTH OF TRANSFER = REQUESTED 
vOV I.UCB(R3),R5 ; GET UCB ADDRESS OF DEVICE 


ne eee ree as ee rr em ee we re ee mem re we ee me ne me ee ee ae re me ee ee ee ee ae ee ee er ee ee ee ee ee ee 


THE INPUT PARAMETERS FOR SIODON ARE: 


RO = FIRST WORD OF I/0 STATUS BLOCK 

Rl = SECOND WORD OF I/0 STATUS BLOCK 

R2 = STARTING AND FINAL RETRY COUNTS 
(IF AN ERROR LOGGING DEVICE) 

R5 = UCB ADDRESS OF UNIT TO COMPLETE 


THE OUTPUT PARAMETERS ARE: 


R4 IS DESTROYED 


=e Te 6 “8s Ne we 


50S: 


TY et i) ee) et en ee Ye ee TY 


me Me Me te we 


™e Me we TO NM 


KATSRV: 


me ™e Se Me NO SH TO MO NO MO Me MH NS MS we 


SAMPLE DRIVER CODE 


CALL SIODON ; COMPLETE THE I/0 

BR BMIN1 :; GO LOOK FOR MORE WORK 
REKKEKKKKREKRKKKKEKRKRKKKKRKKKKK KKK KR KKK KKK KKK KKK KKK 
* * 
* BUFFERED 1/0, CONVERT I/O PACKET TO KERNEL * 
* AST AND EXIT FROM DRIVER * 
ak * 


RHEE EKER KEKE KEKKKEEKEKRKKRKKKKKRKKKKKKKKK KKK KKK KEK 


MOV R4,R3 3; COPY CLOCK BLOCK ADDRESS FOR SREQUE 

MOV I.TCB(R5),RO ; POINT TO TCB OF TASK 

TST (R4)+ 3; SKIP LINK WORD 

MOV #AK.GBI, (R4)+ ; SET A.CBL=AK.GBI 

MOV KISARS, (R4)+ ; SET APR BIAS OF SERVICE ROUTINE 

MOV #KATSRV, (R4)+ ; SET ADDRESS OF PROCESSING ROUTINE 

MOV R5,(R4)+ ; SAVE I/O PACKET ADDRESS IN CLOCK BLOCK 
+—------------ ~~ - - -- - - - - - + - 5 ee 5 + 


THE INPUT PARAMETERS FOR SREQUE ARE: 


tou 


R3 ADDRESS OF THE PACKET TO QUEUE 


| 

| 

| 

| RO 
| 

| 

| NO OUTPUT PARAMETERS. 
| 


| 
| 
| 
TCB ADDRESS TO QUEUE AST BLOCK TO | 
| 
| 
| 
| 


+-~---------------------------- - - --- - +--+ - - = - - + + + + ++ + 
CALLR SREQUE ; QUEUE AST TO TASK 

WAKER KEKEKKERKEKKKKEKEEKRKEKEKEKEKEKKKKKKKRKKKKKKRKRKRKRKRKRKRKRKRKKKKK KKK KKK 
* * 
* KERNEL AST ENTRY POINT = 
ak * 


RAEKKKKEREKKKKEKKREKKEKEKEERKEKKKKREKRKKKEKKKKKKKKKKKKKRKRKRKKKKKKKKKKRKRKKRKEKE 


KKKKKKKEKKKKKKKEEKKKEKKREEKREREKEERKEKEKKREKEKEKKRKKRKRKKKKK KKK KKK 


* * 
* GET PCB ADDRESS AND SEE IF PARTITION IS RESIDENT * 
* * 


HICK FE KKK IIHF IK IK IHR IK HK IKI IIR IIH I IK IIA IIR KAI TRIAS KAIRIE IK 


MOV 10(R3),R5 ; GET I/O PACKET ADDRESS 
MOV I.PRM+16(R5),R1 ; GET PCB ADDRESS OF BUFFER REGION 
BEQ 70$ ; IF EQ THERE IS NO COPY TO PERFORM 


THE INPUT PARAMETERS FOR STSPAR ARE: 


RO = ADDRESS OF THE PACKET (THE KERNEL AST BLOCK) 
Rl = PCB ADDRESS OF THE PCB CONTAINING THE BUFFER 
= TCB ADDRESS OF ASSOCIATED TASK 


| 

| 

| 

| 

| 

| R5 
| 

| THE OUTPUT PARAMETERS ARE 
| 

| 

| 

| 

| 


C = 0 IF REGION IS RESIDENT AND CAN BE ACCESSED 
C = 1 IF REGION IS NOT RESIDENT AND AST HAS 
BEEN QUEUED 
$----------+----------------------- + +--+ 5 -- +--+ - = 5 - = = + 
CALL STSPAR ; REGION IN MEMORY ? 
BCC 60S ; IF CC REGION IN MEMORY 


me "ee Se "SF TVs TH We 


me me Me “6 te 


me Me Me TMH Ne NO MO TH MO MO Ne TO SNe Te TO MS we 


me me ™e Se MO M8 TO NO MO Ow, 


me te Me TO we 


SAMPLE DRIVER CODE 


KEKRKKEEKEKKEKERKEKREKEKEKEKRKERKEEKREEKREKRKEKREEEREKKKEEKEKKKKKKKKRKRKKKRKRKKK 


* * 
* A REGION AST WAS QUEUED. BUMP BUFFERED I/O COUNT * 
* BACK UP TO FORCE I/O RUNDOWN IN CASE OF ABORT AND * 
* EXIT AST SERVICE ROUTINE. * 
* * 
KREKKKKKKEKEKEKKEEKRKEKKERERREKKEKEKEKKKEKRKEEREREKKKRKEKKKKKKKEKKKKEKKRKKRKKEKEK 
MOV I.TCB(R5) ,RO ; GET TCB ADDRESS 

INCB T.TIO(RO) ; BUMP BUFFERED I/O COUNT 

RETURN ; EXIT AST SERVICE ROUTINE 
HWRKEKEKKEKKEKEKKEKEEKKEKKK ERK KEKE KERR KRKKRKEKKKKKKKKRKEK 
* * 
* PERFORM BUFFER COPY OPERATION * 
* * 


KREKKEKKKKEKKKEKEEKEKEKKEKERR EERE EKRKREKKKRKKKKKKKKKKKKEKKKKEKK 


MOV I.TCB(R5) ,RO ; GET TCB ADDRESS OF TASK 
INCB T.1O0C(RO) ; ADJUST REAL I/O COUNT UPWARDS 

MOV I.PRM+4(R5),RO ; GET COUNT OF BYTES 

MOV I.PRM+10(R5),R2 ; SET SOURCE BUFFER ADDRESS 

MOV P.REL(R1),R3 ; GET STARTING BIAS OF PARTITION 

ADD I.PRM(RS) ,R3 ; AND ADD IN OFFSET 

MOV I.PRM+2(R5),R4 ; SET DISPLACEMENT 
+----------~------------ + --- - - + - + ee + ee = - + 


THE INPUT PARAMETERS FOR SBLXIO ARE: 


RO = NUMBER OF BYTES TO MOVE 
Rl = SOURCE APR 5 BIAS 
R2 = SOURCE DISPLACEMENT 
R3 = DESTINATION APR6 BIAS 
= DESTINATION DISPLACEMENT 


THE OUTPUT PARAMETERS ARE 


RO ALTERED 
R1,R3 PRESERVED 
R2,R4 POINT TO LAST BYTE OF SOURCE/DESTINATION +1 


| 
| 
| 
| 
| 
| 
| R4 
| 
| 
| 
| 
| 
| 
| 


4------------------- - - - - -- +--+ - + ee + 
CALL SBLXIO ; COPY THE BUFFER 

MOV I.PRM+10(R5),RO ; GET BUFFER ADDRESS AGAIN 

MOV I.PRM+4(R5),R1 ; GET LENGTH OF BUFFER 

he eee ae a a ae a a a a a a a a a a a a a a a a a a = ee a ee ee + 


THE INPUT PARAMETERS FOR SDEACB ARE: 


ADDRESS OF BLOCK TO DEALLOCATE 
LENGTH OF BLOCK TO DEALLOCATE 


RO 
Rl 


Weil 


NO OUTPUT PARAMETERS. 


aa ae nN SN i ad i ea a ee + 
CALL SDEACB ; DEALLOCATE IT 
HRHKKKKKKKEKEKEKKKEKKEKKKEKEEREKKKEERKERKKKEKKKKKEKKKKRKKKEKKKRKKKRKKKEKKKRKKEK 
* * 
* IF THIS WASN'T A REGION LOAD AST, FINISH THE I/0 : 
“te 


KHER KEKE KEKE KEKE KEREKEKRKEREREKREKEEREEKKKKEKKKKKKKRKKK 


70$ 


=e Te Meo VO Be Ve We WOH We we 


me Me we te we 


=e me Se Me TO MS HH Me MO Me 


me MO Ne TO GO 


me %6 Me MO MO Ge TMA ME 


SAMPLE DRIVER CODE 


MOV I.PRM+14(R5),RO ; RETRIEVE AST BLOCK ADDRESS 

TST (RO) ; WAS THIS A REGION LOAD AST ? 

BNE 80$ ; IF NE YES 

MOV #C.LGTH,R1 ; SET LENGTH OF CLOCK BLOCK 
+-------—-—-----—--------------- - - - -- - - - - + = = 4 


THE INPUT PARAMETERS FOR SDEACB ARE: 


ADDRESS OF BLOCK TO DEALLOCATE 
LENGTH OF BLOCK TO DEALLOCATE 


| 

| 

| 

| RO 
| Rl 
| 

| 

| 


NO OUTPUT PARAMETERS. 


$------ = +--+ + ee 5 5 + + 5 +--+ +--+ + 
CALL SDEACB ; DEALLOCATE CLOCK BLOCK 

MOV I.IOSB(R5),R3  }; GET VIRTUAL ADDRESS OF I/O STATUS BLOCK 
MOV #IS.SUC&377,-(SP) ; SET FIRST I/O STATUS WORD 

MTPD$ (R3)+ ; WRITE FIRST WORD OF STATUS (MAY TRAP) 
MOV I.PRM+4(R5),-(SP) ; SET SECOND WORD OF I/O STATUS 

MTPD$ = (R3) ; WRITE SECOND WORD (MAY TRAP) 

CLR I. IOSB(RS5) ; PREVENT SIODON ATTEMPT TO WRITE STATUS 
MOV R5,R3 ; COPY I/O PACKET ADDRESS 

IMP BMSUC ; FINISH IN COMMON CODE 
KREKEKEKKEKKEKEEKREKEEEKEKEEKKKEKEKKKKKKRKKRKKKKKRKRKKKKRKKKRKKKRKKKKKKKRKRKRKRKEK 
* & 
* RECONVERT REGION LOAD AST TO A TASK AST * 
* * 


KKMREKKEKKEKKEKKEKEEKKEKKREKKKKKRKKKRKRKKRKKRKKKKRKKKRKKRKRKKKKRKKKKRKKK KKK 


MOV RO,R3 ; COPY BLOCK ADDRESS 

CLR 10(RO0) 3; INDICATE NO BUFFER NEXT TIME 

MOV I.TCB(R5) ,RO ; GET TCB ADDRESS 

foo 2 ee 5 ee + 


THE INPUT PARAMETERS FOR SREQUE ARE: 


TCB ADDRESS TO QUEUE AST BLOCK TO 
ADDRESS OF THE PACKET TO QUEUE 


R3 


| 

| 

| 

| RO 
| 

| 

| NO OUTPUT PARAMETERS. 
| 


feo --- + ee + 5 ee = = = + 
CALLR SREQUE ; RE-QUEUE TASK AST AND EXIT AST SERVICE 

KRUREKKKEKKEKKEKKKKEKKKEKKKKKKKEKKKEKKKKKKK KKK KKKKKRKKKKRKRKEK 
* * 
* MISCELLANEOUS ENTRY POINTS * 
* * 


KRHREKKKKRHEKREKKEKEKEKKEKEKEREKREKKEKKEKKKEKKKKKKKKKKKKKKKKKRRKRKKKKRKKKKKKKKKKRKKEE 


KHER KKKKKKKKEKKKSE 


CANCEL ENTRY POINT 


* * 
* * 
* * 
* WE COULD DEQUEUE PENDING CLOCK REQUEST, ETC HERE, * 
* BUT WE DON'T, WE JUST LET THEM COMPLETE LATER * 
* * 
* * 


HWEKKKKKEEKKEEKREKKKKEKKEKKKKKEKKKKKKKKKKKKRKKKKKKKRKKKRKKKKKKKKKKKKRKKKEK 


SAMPLE DRIVER CODE 


BMCAN: 
: See e SoC SESS CLS CLS SCLC SSL SLITS LEST SSIS OCIS LICLCTOSCTSCITOCC LCOS LSE LSS} 
- * * 
a 
, * T IM EOUT ENTRY POINT * 
. * * 
a 
* SINCE THERE'S NO PHYSICAL DEVICE TO TIME OUT, NO-OP * 
. * x 
: KKK KI KKK KK HK IK II KI KK III I IK RIK KK IK III IKK KIKI KKK IKKE IKE ERIK RK K 
BMOUT: 
; KI KKK KK KH KK KK IKI HK KICK II KI IK I KK IKK IKI REIKI KIKI KKK EKA AKAIKE 
F * * 
c 
: * POW ERFATIL ENTRY POINT * 
. * * 
e 
* POWERFAIL DOESN'T AFFECT NON-EXISTENT DEVICES * 
e * * 
d SECC CEP CCS CLS CLE LIS SSS SSIS LS SCS SLL LTSCLTSLLCLC TSC CSOCCLESCL ESL LLL ELS) 
BMPWF: 
; cece ee CeCe CCC CLCCLCCLCLCCS SCLC CO CTC LCCC CLC CCCCCCC CTCL TTT TTL) 
e * * 
7 * STATUS CHANGE ENTRY POINTS * 
e * * 
a 
; * DON'T NEED TO TOUCH NON-EXISTENT DEVICE, JUST LET * 
. * EXEC PUT DEVICE ON/OFF LINE * 
. * x 
: KEK KK KK IK IK KK KK IK II IK II I KIKI KIKI KIKI III KIKI IEEE RRR KKK 
BMKRB: 
BMUCB: 

RETURN ; ALL THESE ARE NO-OP FOR NOW 

-END 


APPENDIX A 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


This appendix describes the RSX-11M-PLUS system macros that supply 
symbolic offsets for data structures listed in Table A-l. 


The data structures are defined by macros in the Executive macro 
library. To reference any of the data structure offsets from your 
code, include the macro name in an .MCALL directive and invoke the 


macro. For example: 


-MCALL DCBDFS$ 
DCBDFS ;Define DCB offsets 


NOTE 


All physical offsets and bit definitions 
are subject to change in future releases 
of the operating system. Code that 
accesses system data structures should 
always use the symbolic offsets rather 
than the physical offsets. 


The first two arguments, <:> and <=>, make all definitions global. If 
they are left blank, the definitions will be local. The SYSDEF 
argument causes the variable part of a data structure to be defined. 


All of these macros are in the Executive macro library, 
LB: (1,1]EXEMC.MLB. All except F11DFS, ITBDF$, MTADFS, OLRDFS, and 
SHDDFS are also in the Executive definition Library, 


LB: [1,1]EXELIB. OLB. 


Table A-1l 
Summary of System Data Structure Macros 


Task abort and termination 
notification message codes 


ABODFS 


Accounting data structures 
(user account block, task account 
block, system account block) 


ACNDFS 


Clock queue control block 


CLKDFS 


(continued on next page) 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


Table A-l (Cont.) 
Summary of System Data Structure Macros 


<€:>,<=> Controller table 


CTBDIFS$ 


Device control block 


DCBDFS | <:>,<=>,SYSDEF 


EPKDFS$ | <:>,<=> Error message block 


Files-11 data structures 
(volume control block, mount list 
entry, file control block, file 
window block, locked block list 
node) 


F1IDFS | <:>,<=>,SYSDEF 


Task header and window block 


HDRDEF'$ 


<:>,<=> 


HWDDF'S Hardware register addresses and 


feature mask definitions 


<:>,<=>,SYSDEF 


ITBDFS | <:>,<=>,SYSDEF Interrupt transfer block 


Controller request block 


KRBDF$ 


<2>,<=> 


Logical assignment control block 


LCBDES | <:>,<=> 


MTADES ANSI magtape data structures 


(volume set control block) 


<:>,<=> 


OLRDF$ On-line reconfiguration interface 


Partition control block and 
attachment descriptor 


PCBDFS | <:>,<=>,SYSDEF 


PKTDES I/O packet, AST control block, 
offspring control block, group 
global event flag control block, 


and CLI parser block 


€2>,<=> 


Status control block and UMR 
assignment block 


SCBDFS$ | <:>,<=>,SYSDEF 


Shadow recording linkage block 


SHDDFS$ 


<:>,<=> 


Task control block 


TCBDFS$ 


€:>,<=>,SYSDEF 


UCBDFS | <:>,<=>,TTDEF,SYSDEF Unit control block 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


ABODF$ 
ABODFS 
? 
; TASK ABORT CODES 
a 
; NOTE: S.COAD-S.CFLT ARE ALSO SST VECTOR OFFSETS 
v 
S.CACT=-4, ;TASK STILL ACTIVE 
S.CEXT=-2. ;TASK EXITED NORMALLY 
S.COAD=0. ;ODD ADDRESS AND TRAPS TO 4 
S.CSGF=2. ;SEGMENT FAULT 
S.CBPT=4. ;BREAK POINT OR TRACE TRAP 
S.CIOT=6. ;IOT INSTRUCTION 
S.CILI=8. ; ILLEGAL OR RESERVED INSTRUCTION 
S.CEMT=10. ;NON RSX EMT INSTRUCTION 
S.CTRP=12. ;TRAP INSTRUCTION 
S.CFLT=14. 311/40 FLOATING POINT EXCEPTION 
S.CSST=16. ;SST ABORT-BAD STACK 
S.CAST=18. ;AST ABORT-BAD STACK 
S.CABO=20. ;ABORT VIA DIRECTIVE 
S.CLRF=22. ;TASK LOAD REQUEST FAILURE 
S.CCRF=24. ;TASK CHECKPOINT READ FAILURE 
S.IOMG=26. ;TASK EXIT WITH OUTSTANDING I/0 
S.PRTY=28. ;TASK MEMORY PARITY ERROR 
S.CPMD=30. ;TASK ABORTED WITH PMD REQUEST 
S.CELV=32. ;TI: VIRTUAL TERMINAL WAS ELIMINATED 
S.CINS=34. ;TASK INSTALLED IN 2 DIFFERENT SYSTEMS 
S.CAFF=36. ;TASK ABORTED DUE TO BAD AFFINITY (REQUIRED 
;BUS RUNS ARE OFFLINE OR NOT PRESENT) 
S.CCSM=38. ;BAD CSM PARAMETERS OR BAD STACK 
S.COTL=40. :;TASK HAS RUN OVER ITS TIME LIMIT 


=e Me we 


T.NDNR=0 
T.NDSE=2 
T.NCWF=4 
T.NCRE=6 
T.NDMO=8. 
T.NUER=10. 
T.NLDN=12. 
T.NLUP=14. 
T.NCFI=16. 
T.NUDE=18. 
T.NMPE=20. 
T.NKLF=22. 
T.NAAF=24. 
T.NTAF=26. 
T.NDEB=28. 
T.NRCT=30. 
T.NWBL=32. 


TASK TERMINATION NOTIFICATION MESSAGE CODES 


;DEVICE NOT READY 

;DEVICE SELECT ERROR 

;CHECKPOINT WRITE FAILURE 

;CARD READER HARDWARE ERROR 
7DISMOUNT COMPLETE 

; UNRECOVERABLE ERROR 

;LINK DOWN (NETWORKS) 

;LINK UP (NETWORKS) 

;CHECKPOINT FILE INACTIVE 

7; UNRECOVERABLE DEVICE ERROR 
;MEMORY PARITY ERROR 

;UCODE LOADER NOT INSTALLED 
;ACCOUNTING ALLOCATION FAILURE 
;ACCOUTING TAB ALLOCATION FAILURE 
;TASK HAS NO DEBUGGING AID 
;REPLACEMENT CONTROL TASK NOT INSTALLED 
*;WRITE BACK CACHING DATA LOST 
UNIT WRITE LOCKED 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


ACNDF$ 


000000 
00000°? 
000003 
00000+ 
000012 
000012 


00001' 
000020) 


00002. 
00002:: 
000022: 


00002: 
00002E. 
00003: 
000036 
00004: 
00005( 
00005€ 
000062 
000064 
OO006S 


OO0065S 
OO0006E 
00007C 
000072 
000074 
000102 
000104 


000112 
000130 
000131 
000132 
000002 


ACNDFS$ 


; ACCOUNTING 


‘ 
’ 
° 
a 
° 
f 
° 
‘ 


-=0 
B.LNK: 
B.TYP: 
B.LEN: 
B.TIM: 
B.HID=. 
B.UID: 


B.ACN: 
B.TID: 


B.HEND=. 
SSSHLN=. 


; ACCUMULATION FIELDS FOR TAB, 


f 

B.CPU: 

B.DIR: 

B.QIO: 

B. TAS: 

B.MEM: 

B.BEG: 

B.CPUL: 
B.PNT: 

B.STM: 


SSSTLN=. 


-ASECT 


. BLKW 
- BLKB 
- BLKB 
- BLKW 


- BLKW 


- BLKW 
- BLKB 


. BLKB 


- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
» BLKW 
- BLKW 
- BLKW 
- BLKB 


BLOCK OFFSET AND STATUS DEFINITIONS 
FOR EACH TRANSACTION TYPE. 


HEADER COMMON TO ALL TRANSACTIONS 


ad LINK TO NEXT IN SYSLOG QUEUE 
iL ; TRANSACTION TYPE 
I ; TRANSACTION LENGTH 
3 ;ENDING TIME OF TRANSACTION 
;START OF HEADER IDENTIFICATION AREA 
2 UNIQUE SESSION IDENT 
;FIRST WORD-RAD50, SECOND-BINARY 
i ; ACCOUNT NUMBER 
1 ;ASCII TERMINAL TYPE (V,T,B OR C) 
; (VIRTUAL, REAL,BATCH, OR CONSOLE) 
1 7; UNIT NUMBER 


END OF HEADER ID AREA 
;HEADER LENGTH 


UAB, AND SAB 
CPU TIME USED 

DIRECTIVE COUNT 

;TOTAL QIO$ COUNT 

;TOTAL TASK COUNT 

; RESERVED 

;BEGINNING/LOGIN TIME 

;CPU LIMIT 

;POINTER TO HIGHER LEVEL TOTALS 
;STATUS MASK 

;TOTAL'S LENGTH 


; TOTAL 
; TOTAL 


MmrRMWWNNDN ND DN 


; USER ACCOUNT BLOCK (UAB) 


7 
B.USE: 
B.ACT: 
B.UUIC 
B.UCB: 
B.LGO: 


B.ULNK: 
B.RNA: 


B.NAM: 


B.ULEN=. 


=SSSTLN 


NOTE: 


- BLKB 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 


- BLKB 
- BLKB 
- BLKB 


$$S=<.+77>/100 


UAB'S MUST END ON A WORD BOUNDRY 


;START AFTER TOTALS 
1 ;USE COUNT 
1 ;NUMBER OF CURRENTLY ACTIVE TASKS 
i ;LOGIN UIC 
i ;POINTER TO UCB 
3 ;LOGOFF TIME 
1 ;LINK TO NEXT UAB 
3 ;LOC IN SYSTEM ACCNT FILE 
; (OFFSET, VBN-HI, VBN-LO) 


14. ;LAST NAME OF USER 
1 ;FIRST INITIAL OF USER 
i ;UNUSED BYTE 


;UAB LENGTH 
;UAB LENGTH (ROUNDED UP TO 32 WORD BOUND) 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


000065 
000066 
000072 
000074 
000076 
000100 
000102 
000104 
000110 
000114 
000120 
000124 
000002 


000065 
000066 
000070 
000072 
000076 
000102 
000106 
000112 
000120 
000122 
000124 
000126 
000134 
000136 
000140 
000144 
000146 
000154 
000160 
000162 


000162 
000202 
000222 
000242 
000262 
000302 
000322 
000342 
000362 
000366 
000372 
000376 


° 
s 
e 
’ 
° 
’ 
. 
a 
e 


=SSSTLN 
B.PRI: 
B.TNAM: 
B.TCB: 
B.TST3: 


B.CUIC: 
B.PUIC: 
B.CTXT: 
B.TCKP: 
B.OVLY: 
B.EXST: 
B.TLEN=. 


NOTE: 


.- BLKB 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
» BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 


NNNNEP REE Nie 


B.TBLK=<.+77>/100 


=SSSTLN 

B.SHDN: .BLKB 
B.UHD: .BLKW 
B.ULO: .BLKW 
B.ULT: .BLKW 
B.CKP: .BLKW 
B.SHF: .BLKW 
B.RND: .BLKW 
B.FID: .BLKW 
B.DVNM: .BLKB 
B.UNIT: .BLKW 
B.EXTS: .BLKW 
B.LSCN: .BLKW 
B.SCNR: .BLKW 
B.DSCN: .BLKW 
B.STSP: .BLKW 
B.SYSM: .BLKW 
B.CKUS: .BLKW 
B.CKSP: .BLKW 
B.CKAL: .BLKW 
B.SLEN=. 


me Se ws 


B.CPUT: 
B.CTXP: 
B.IDCT: 
B.QIOC: 
B.MIOC: 
B.AIOC: 
B.IPSN: 
B.IPRC: 
B.CKEX: 
B.CFCL: 
B.CFRK: 
B.TLOD: 


- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 


MPNOWRrRNY RF RWRrREHRNWNNNDN DN KK F&F 


TASK ACCOUNT BLOCK (TAB) 
THE TAB MUST END ON A WORD BOUNDRY 


;STARTS AFTER TOTALS 
;HIGHEST RUNNING PRIORITY 


;TASK NAME 
;TCB ADDRESS 


;T.ST3 FROM TASK'S TCB 


ACNDF$ (Cont.) 


;RESERVED FOR FUTURE STATUS BITS 


;CURRENT UIC OF TASK 
; PROTECTION UIC OF TASK 
;NUMBER OF CONTEXT LOADS 


;TIMES TASK HAS BEEN CHECKPOINTED 
;NUMBER OF DISK OVERLAY LOADS 


; EXIT STATUS AND ABORT CODE 


;TAB LENGTH 


;NUMBER OF SEC POOL BLOCKS IN TAB 


;START AFTER TOTALS 


;ACCOUNTING SHUTDOWN REASON CODE 


;UAB LISTHEAD 


;NUMBER OF USERS CURRENTLY LOGGED ON 


; TOTAL NUMBER OF LOGONS 
; TOTAL NUMBER OF CHECKPOINTS 


; TOTAL NUMBER OF SHUFFLER RUNS 


;NUMBER OF CPU INTERVALS ROUNDED UP TO 1 
;FILE-ID OF TRANSACTION FILE 
;DEVICE OF TRANSACTION FILE 
; UNIT OF TRANSACTION FILE 


; EXTEND SIZE FOR TRANSACTION FILE 


;TIME OF LAST SCAN 
;SCAN RATE IN SECONDS 


;STATISTICAL SCAN RATE (IN SEC) 


; RESERVED 
; RESERVED 
; RESERVED 
; RESERVED 
; RESERVED 
;SAB LENGTH 


NEW FIELDS FOR EXTENDED ACCOUNTING 


;CPU TIME USED PER PROCESSOR 
;NUMBER OF CONTEXT SWITCHES 


(PER PROC) 


;NUMBER OF IDLE LOOP ENTRIES (PER PROC) 
;NUMBER OF I/0 INITIATIONS (PER PROC) 
;MASS STORE I/0 COMPLETIONS (PER PROC) 
;ALL I/O COMPLETIONS (PER PROC) 

;IP INTERRUPTS SENT (PER PROC) 

;IP INTERRUPTS RCVD (PER PROC) 
;CHECKPOINT DUE TO EXTEND TASKS 


;CALLS TO CFORK 


7;CFORK FORKS 
;TASK LOADS 


A-5 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


ACNDFS$ (Cont.) 


000402 B.RLOD: .BLKW 2 ;REGION LOADS 

00040€ - BLKB 82. ;BUMP SIZE TO NEXT 32 WORD BLOCK 

00034€ B.SSBL=.-B.SLEN ;EXTRA LENGTH OF SYSTEM STATISTICS BLOCK 
O0000€ S$$S$=<.+77>/100 ;SAB LENGTH (ROUNDED UP TO 32 WORD BOUND) 


SYSLOG STARTUP TRANSACTION 


e me =e Be 


=S$SHLN ;START AFTER HEADER 
00002z B.SSLN=. ; TRANSACTION LENGTH 


; CRASH RECOVERY TRANSACTION 


=SSSHLN ;START AFTER STANDARD HEADER 
000022 B.CTLS: .BLKW 3 ; TIME OF LAST SCAN BEFORE CRASH 
00003C B.CSRT: .~BLKW i ;SCAN RATE BEFORE CRASH 
00003Z B.CRSN: .BLKB 60. ;ASCII TEXT EXPLAINING CRASH 
00012€ B.CLEN=,. 7TRANSACTION LENGTH 


7 


; INVALID LOGIN TRANSACTION 


’ 

-=SSSHLN ; 
000022 B.INAM: .BLKB 14. ;NAME FROM LOGIN LINE 
00004C B.IUIC: .BLKB 6. ;UIC FROM LOGIN LINE 
00004€ B.IPSW: .BLKB 6. ;PASSWORD FROM LOGIN LINE 
000054 B.ILEN=. ; TRANSACTION LENGTH 


; DEVICE TRANSACTIONS (ALLOCATION, DEALLOCATION, MOUNT, AND 


; DISMOUNT) 
-=SSSHLN ; 

000022 B.DNAM: .BLKW 1 ;ASCII DEVICE NAME 

000024 B.DUNT: .BLKB 1 ;OCTAL DEVICE UNIT NUMBER 

000025 B.DLEN=. ; TRANSACTION LENGTH FOR ALL, DEA, AND DMO 

000025 .BLKB 1 ;UNUSED BYTE 

000026 B.DLBL: .BLKW 6 ; VOLUME LABEL 

000042 B.DMST: .BLKW 1 ;MOUNT STATUS BITS 

000044 B.DUIC: .BLKW 1 ;OWNER UIC 

000046 B.DVPR: .BLKW 1 ; VOLUME PROTECTION CODE 

000050 B.DACP: .BLKW 2 ;NAME OF ACP FOR DEVICE 

000054 B.MLEN=. ;LENGTH OF MOUNT TRANSACTION 


STATUS BITS FOR MOUNT STATUS MASK (B.DMST) 


e me we 


BM.SHR=1 ;DEVICE IS MOUNTED SHARED 
BM.NOS=2 ;DEVICE IS MOUNTED NOSHARE 
BM.SYS=4 ;DEVICE IS MOUNTED FOR THE SYSTEM (PUBLIC) 
BM. FOR=10 ;DEVICE IS MOUNTED FOREIGN 
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ACNDF$ (Cont.) 


; 
; SYSTEM TIME CHANGE TRANSACTION 
; 


=SSSHLN ; 
000022 B.TOLD: .BLKB 6 ;OLD TIME (YR, MON, DAY, HR, MIN, SEC) 
000030 B.TNEW: .BLKB 6 ;NEW TIME (YR, MON, DAY, HR, MIN, SEC) 
000036 B.TMLN=. ;TRANSACTION LENGTH 


; 
; PRINT DESPOOLER TRANSACTION 
; 


=$SSHLN ;START AFTER HEADER 
000022 B.PNAM: .BLKW 3 ;PRINT JOB NAME’ (RADS5O) 
000030 B.PPGS: .BLKW 1 ;PAGE COUNT 
000032 B.PNFI: .BLKW 1 ;NUMBER OF FILES PRINTED 
000034 B.PFRM: .BLKB 1 ;FORM NUMBER 
000035 B.PPRI: .BLKB 1 ;PRINT PRIORITY 
000036 B.PDEV: .BLKW 1 ;PRINT DEVICE NAME (ASCIT) 
000040 B.PPUN: .BLKB 1 ;UNIT NUMBER OF PRINT DEVICE 
000041 B.PLEN=. ; TRANSACTION LENGTH 


7 
; CARD READER SPOOLING TRANSACTION 
i 


=S$SSHLN ;START AFTER HEADER 


000022 B.RNAM: .BLKW 3 ;BATCH OR PRINT JOB NAME 

000030 B.RCDS: .BLKW £ ;NUMBER OF CARDS READ 

000032 B.RDEV: .BLKW 1 ;READER DEVICE NAME (ASCII) 

000034 B.RUNT: .BLKB i ; UNIT NUMBER OF READER DEVICE 
000035 B.RSOP: .BLKB 1 ;SUBMIT OR PRINT (O=SUBMIT, 1=PRINT) 
000036 B.RLEN=. ; TRANSACTION LENGTH 


; 
; LOGIN TRANSACTION 


=S$SSHLN ;START AFTER HEADER 
000022 B.LUIC: .BLKW 1 ;LOGIN UIC 
000024 B.LNAM: .BLKB Tas ;USER'S LAST NAME 
000042 . BLKB 1 ;AND FIRST INITIAL 
000043 B.LLEN=. ; TRANSACTION LENGTH 


RESET TRANSACTION PARAMETERS 


=e te Ge 


-=SSSHLN ;AFTER HEADER 

000022 B.OFID: .BLKW ;FILE-ID OF OLD TRN. FILE 
000030 B.ODNM: .BLKB :;DEVICE OF OLD TRN. FILE 
000032 B.OUNT: .BLKW ;UNIT OF OLD TRN. FILE 
000034 B.NFID: .BLKW ;FILE+ID OF NEW TRN. FILE 
000042 B.NDNM: .BLKB ;DEVICE OF NEW TRN. FILE 
000044 B.NUNT: .BLKW ;UNIT OF NEW TRN. FILE 
000046 B.OEXS: .BLKW ;EXT. SIZE FOR OLD TRN. FILE 
000050 B.NEXS: .BLKW ;EXT. SIZE FOR NEW TRN. FILE 
000052 B.OSCR: .BLKW ;OLD SCAN RATE IN SECONDS 
000054 B.NSCR: .BLKW ;NEW SCAN RATE IN SECONDS 


KR RPE ROWED WwW 


ACNDF$ (Cont.) 


000056 
000060 
00006”? 
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B.ODSC: .~BLKW 
B.NDSC: .~BLKW 


B.RTLN=. 


e@ eo te Me TO MO 


‘ 

BT. SAB=1 
BT. UAB=2 
BT. TAB=3 
BT.SS=11 
BT. INV=12 
BT. TIM=13 
BT.ALL=14 
BT. DEA=15 
BT.MOU=16 
BT.DMO=17 
BT. PRT=20 
BT.DIR=21 
BT. VOL=22 
BT. LOG=23 
BT. CRH=24 
BT.DST=25 
BT.RTP=26 
BT. INP=27 


o ™e Me 


BS.ACT=200 
BS.CRH=100 
BS.LGO=40 
BS.C0=40 

BS. TML=20 
BS. ZER=10 
BS.SCN=4 


e¢ me 


BF.DST=40000 
BF .WRT=2000 
BF.SCN=1000 


BF.SLR=400 
BF. ERR=200 
BF.STR=100 
BF.LSS=40 


BF. TRN=10 
BF.XTK=4 
BF. TSK=2 
BF. XAC=1 


TRANSACTION TYPES 


000 THRU 127 
128 THRU 255 


;OLD STATISTICAL SCAN RATE 
;NEW STATISTICAL SCAN RATE 


RESERVED FOR DEC USE 
RESERVED FOR CUSTOMER USE 


;SYSTEM ACCOUNT BLOCK (SAB) 

;USER ACCOUNT BLOCK (UAB) 

;TASK ACCOUNT BLOCK (TAB) 

;SYSLOG STARTUP TRANSACTION 

; INVALID LOGIN TRANSACTION 

;SYSTEM TIME CHANGE TRANSACTION 

;ALLOCATE DEVICE TRANSACTION 

;DEALLOCATE DEVICE TRANSACTION 

;MOUNT DEVICE TRANSACTION 

;DISMOUNT DEVICE TRANSACTION 

PRINT DESPOOLER TRANSACTION 

;DISK ACCOUNTING BY DIRECTORY (UNSUPPORTED) 
;DISK ACCOUNTING BY VOLUME (UNSUPPORTED) 
;LOGIN TRANSACTION 

;CRASH RECOVERY TRANSACTION 

;DEVICE STATISTICS (UCB EXTENSION) 

;RESET TRANSACTION PARAMETERS 

7;CARD READER SPOOLING TRANSACTION 


STATUS MASK BIT DEFINITIONS (B.STM) 


;CONTROL BLOCK ACTIVE 

;RECORD FROM "TMP" FILE AFTER SYSTEM CRASH 
; LOGGED OFF WITH OUTSTANDING ACTIVITY (UAB) 
;TASK'S TI: IS CO: (TAB ONLY) 

;TAB EXISTS ONLY FOR TIME LIMIT (TAB ONLY) 
;LAST CPU INTERVAL WAS OF LENGTH ZERO 

; TRANSACTION READY FOR WRITE TO SCAN FILE 


ACCOUNTING FEATURE MASK (SACNFE) 


;STATISTICAL SCAN RATE 

;FORCE SYSLOG TO WRITE ITS BUFFER 
;SCAN REQUESTED 

;SYSLOG IS RUNNING (NOT STOPPED) 
;ACCOUNTING STOPPED DUE TO FATAL ERROR 
;ACCOUNTING IS STARTING UP / SHUTTING DOWN 
; ACCUMULATE SYSTEM STATISTICS 

; (POINT UAB TO SAB) 

;OUTPUT TO TRANSACTION FILE 
;CHECKPOINT REQUEST IS DUE TO EXTKS 
;TASK ACCOUNTING TURNED ON 

; EXTENDED ACCOUNTING ASSEMBLED IN 
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000000 
000003 
000006 
000014 
000032 
000046 
000054 
000056 
000062 
000064 
000070 
000074 
000076 


me se Me Se MO He MO MO 
2 
~ 


B.MAXL=1 
B.MINL=$ 


-=0 
A.GRP: 
A.MBR: 
A.PSWD: 
A.LNM: 
A.FNM: 
A.LDAT: 
A.NLOG: 
A.SYDV: 
A.ACN: 
A.CLI: 


A.LPRV: 
A.SID: 
A. LEN=12 


28. 
SSHLN 


- PSECT 


ACTDFS 


-ASECT 


- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
8. 


ACNDFS$ (Cont.) 


SHUTDOWN CODES (B.SHDN) 


MAINTENANCE 

REBOOT 

SCHEDULED SHUTDOWN 

ACCOUNTING SHUTDOWN BY TASK "SHUTUP" 
OTHER 


;MAXIMUM TRANSACTION LENGTH 
;MINIMUM TRANSACTION LENGTH 


ACTDF$ 


;GROUP CODE (ASCIT) 
;MEMBER CODE 

; PASSWORD 

;LAST NAME 

;FIRST NAME 

;DATE OF LAST LOG ON (DD/MM/YY HH:MM:SS 
TOTAL NUMBER OF LOGONS 

;DEFAULT SYSTEM DEVICE 

;ACCOUNT NUMBER (BINARY) 

;RAD50 USER CLI 

; UNUSED 

;LOGIN PRIVILEGE WORD 

;SESSION IDENTIFIER 

;LENGTH OF CONTROL BLOCK 


No 


RPRNONEF PND FR DW Ww 


BIT DEFINITIONS ON A.LPRV - LOGIN PRIVILEGE BITS 


: 
i 
; 
AL.SLV=1 


-PSECT 


7;SLAVE TERMINAL ON LOGIN 
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CLKDF$ 


000000 
000002 
000003 
000004 
000006 


000012 
000014 
000016 
000020 


000012 
000016 
000020 


000012 


CLKDFS 


=e 


CLOCK QUEUE 


“ee 


CLOCK QUEUE 


™e ™e me MB Me Me Ne MO fe 


C.MRKT=0 
C.SCHD=2 
C.SSHT=4 
C.SYST=6 
C.SYTK=8. 


C.CSTP=10. 


; CLOCK QUEUE 


-ASECT 


C.LNK: - BLKW 
C.ROT: - BLKB 
C.EFN: .BLKB 
C.TCB: .BLKW 
C.TIM: .BLKW 


° 
c 
e 
‘ 


CLOCK QUEUE 


-=C.TIM+4 
C.AST: .BLKW 
C.SRC: .BLKW 
C.DST: .BLKW 
- BLKW 


; CLOCK QUEUE 
; DEFINITIONS 
; 


ul 


C.TIM+4 

C.RSI: .BLKW 
C.UIC: .BLKW 
C.UAB: .BLKW 


CONTROL BLOCK OFFSET DEFINITIONS 


CONTROL BLOCK 


THERE ARE FIVE TYPES OF CLOCK QUEUE CONTROL BLOCKS. EACH CONTROL 
BLOCK HAS THE SAME FORMAT IN THE FIRST FIVE WORDS AND DIFFERS IN 
THE REMAINING THREE, 


THE FOLLOWING CONTROL BLOCK TYPES ARE DEFINED: 


;MARK TIME REQUEST 

;TASK REQUEST WITH PERIODIC RESCHEDULING 
;SINGLE SHOT TASK REQUEST 

;SINGLE SHOT INTERNAL SYSTEM SUBROUTINE 


; (IDENT) 

;SINGLE SHOT INTERNAL SYSTEM SUBROUTINE 
; (TASK) 

;CLEAR STOP BIT (CONDITIONALIZED ON 
;SHUFFLING) 


CONTROL BLOCK TYPE INDEPENDENT OFFSET DEFINTIONS 


;CLOCK QUEUE THREAD WORD 

;REQUEST TYPE 

; EVENT FLAG NUMBER (MARK TIME ONLY) 

7TCB ADR OR SYSTEM SUBROUTINE IDENTIFICATION 
;ABSOLUTE TIME WHEN REQUEST COMES DUE 


NPR RH 


CONTROL BLOCK-MARK TIME DEPENDENT OFFSET DEFINITIONS 


;START OF DEPENDENT AREA 

;AST ADDRESS 

; FLAG MASK WORD FOR 'BIS' SOURCE 
;ADDRESS OF 'BIS' DESTINATION 

; UNUSED 


ee 


CONTROL BLOCK-PERIODIC RESCHEDULING DEPENDENT OFFSET 


;START OF DEPENDENT AREA 


2 ;RESCHEDULE INTERVAL IN CLOCK TICKS 
1 ;SCHEDULING UIC 
1 ;POINTER TO ASSOCIATED UAB 


CONTROL BLOCK-SINGLE SHOT DEPENDENT OFFSET DEFINITIONS 


;START OF DEPENDENT AREA 
2 7TWO UNUSED WORDS 


A-10 
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CLKDF$ (Cont.) 


000016 .- BLKW 1 ;SCHEDULING UIC 
000020 - BLKW 1 ;C.UAB 
; 
; CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT INTERNAL SUBROUTINE OFFSET 
; DEFINITIONS 
; 
; THERE ARE TWO TYPE CODES FOR THIS TYPE OF REQUEST: 
; . 
; TYPE 6 = SINGLE SHOT INTERNAL SUBROUTINE WITH A 16 BIT VALUE 
; AS AN IDENTIFIER. 
; 
; TYPE 8 = SINGLE SHOT INTERNAL SUBROUTINE WITH A TCB ADDRESS 
: AS AN IDENTIFIER. 
; 
-=C. TIM+4 7;START OF DEPENDENT AREA 
000012 C.SUB: .BLKW 1 ;SUBROUTINE ADDRESS 
000014 C.AR5: .BLKW - ;RELOCATION BASE (FOR LOADABLE DRIVERS) 
000016 C.URM: .BLKW 1 ;URM TO EXECUTE ROUTINE ON 
7(MP SYSTEMS, C.SYST ONLY) 
000020 - BLKW Ay ; UNUSED 
000022 C.LGTH=. ;LENGTH OF CLOCK QUEUE CONTROL BLOCK 


- PSECT 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


CTBDF$ 


CTBDFS 


; CONTROLLER TABLE (CTB) 


THE CONTROLLER TABLE IS A CONTROL BLOCK THAT CONTAINS A VECTOR 
Of KRB ADDRESSES. THIS VECTOR MAY BE ADDRESSED BY THE CONTROLLER 
INDEX TAKEN FROM THE INTERRUPT PS BY SINTSV/SINTSE. 


-ASECT 
-=177756 
LITIS6 eC K: - BLKW ° ;START OF CLOCK BLOCK (IF ANY) 
177776 L.IZB: .BLKW ;ICB CHAIN FOR THIS CTB 
000000 L.LNK: - BLKW ;CTB LINK WORD 
000002 L.NAM: .BLKW ;GENERIC CONTROLLER NAME (ASCIT) 


;DCB ADDRESS OF THIS DEVICE 
;NUMBER OF KRB ADDRESSES IN TABLE 
;CTB STATUS BYTE 

;START OF KRB ADDRESSES 


000004 L.DCB: .BLKW 
000006 L.NJM: .BLKB 
000007 L.STS: .BLKB 
000010 L.KRB: .BLKW 


ie) 


NOTE: THE SYMBOL S$XYCTB:: IS DEFINED FOR EACH CTB, WHERE THE 
CHARACTERS XY ARE THE SAME AS THOSE STORED IN L.NAM. THE 
SYMBOL IS NOT THE START OF THE CTB, BUT INSTEAD THE START OF 
THE KRB TABLE AT THE END OF THE CTB (L.KRB).. 


me me Me Me Me Ne 


«PSECT 


. 
f 


; CONTROLLER TABLE STATUS BYTE BIT DEFINITIONS 


LS.CLK=1 ;CLOCK BLOCK AT TOP OF CTB (1=YES) 

LS.MDC=2 ;MULTIDRIVER CTB (1=YES) 

LS.CBL=4 ;CLOCK BLK LINKED INTO CLK Q (1=YES) 

LS.CIN=10 ;CONT. USE COMMON INT TABLE (1=YES) 

LS.NET=20 ;THIS IS DECNET DEVICE. ICB'S IN K.PRM 
7; (1=YES) 


° 
c 
. 
‘ 


COMMON INTERRUPT TABLE DISPATCH ENTRY POINTS 


CI.CSR=-6 ;CSR TEST ENTRY POINT 

CI.KRB=-4 7;KRB STATUS CHANGE ENTRY POINT 
CI. PWF=-2 ; POWERFAIL ENTRY POINT 

CI.INT=0 ;COMMON INTERRUPT ADDRESS 
CI.DCB=2 ;START OF DCB TABLE (0 ENDS TABLE) 


000000 
000002 
000004 
000006 
000007 
000010 
000012 
000014 
000016 
000020 
000022 
000024 
000026 
000030 
000032 
000034 
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DCBDF$ 


DCBDF$ ,,SYSDEF 


DEVICE CONTROL BLOCK 


THE DEVICE CONTROL BLOCK (DCB) DEFINES GENERIC INFORMATION ABOUT A 
DEVICE TYPE AND THE LOWEST AND HIGHEST UNIT NUMBERS. THERE IS AT 
LEAST ONE DCB FOR EACH DEVICE TYPE IN A SYSTEM. FOR EXAMPLE, IF 
THERE ARE TELETYPES IN A SYSTEM, THEN THERE IS AT LEAST ONE DCB 
WITH THE DEVICE NAME 'TT'. IF PART OF THE TELETYPES WERE 
INTERFACED VIA DL11-A'S AND THE REST VIA A DH11, THEN THERE WOULD 
BE TWO DCB'S. ONE FOR ALL DL11-A INTERFACED TELETYPES, AND ONE 
FOR ALL DH11 INTERFACED TELETYPES,. 


me Te Me MO Ne Te Te TS Te NH Ne we 


-ASECT 
-=0 
D.LNK: .BLKW ai ;LINK TO NEXT DCB 
D.UCB: .BLKW 1 ;POINTER TO FIRST UNIT CONTROL BLOCK 
D.NAM: .BLKW i ;GENERIC DEVICE NAME 
D.UNIT: .BLKB 1 ; LOWEST UNIT NUMBER COVERED BY THIS DCB 
- BLKB 1 ;HIGHEST UNIT NUMBER COVERED BY THIS DCB 
D.UCBL: .BLKW 1 ; LENGTH OF EACH UNIT CONTROL BLOCK IN BYTES 
D.DSP: .BLKW 1 ;POINTER TO DRIVER DISPATCH TABLE 
D.MSK: .BLKW A ; LEGAL FUNCTION MASK CODES 0-15. 
- BLKW L ;CONTROL FUNCTION MASK CODES 0-15. 
- BLKW ui ;NOP'ED FUNCTION MASK CODES 0-15. 
- BLKW a ;ACP FUNCTION MASK CODES 0-15. 
- BLKW 1 ; LEGAL FUNCTION MASK CODES 16.-31. 
- BLKW ui ;CONTROL FUNCTION MASK CODES 16.-31. 
- BLKW i ;NOP'ED FUNCTION MASK CODES 16.-31. 
- BLKW 1 ;ACP FUNCTION MASK CODES 16.-31. 
D.PCB: .BLKW A ; LOADABLE DRIVER PCB ADDRESS 
» PSECT 


DRIVER DISPATCH TABLE 


D. VDEB=-2 
D. VCHK=-4 


OFFSET DEFINITIONS 


;DEALLOCATE BUFFER(S) 

;ADDRESS OF ROUTINE CALLED TO VALIDATE 
AND CONVERT THE LBN. USED BY DRIVERS 
;THAT SUPPORT SEEK OPTIMIZATION. 


D. VNXC=~-4 ;ADDRESS OF ROUTINE IN TTDRV CALLED TO 
;HAVE IT SEND THE NEXT COMMAND IN THE 
;TYPEAHEAD BUFFER TO MCR... 

D.VINI=0 ;DEVICE INITIATOR 

D. VCAN=2 ;CANCEL CURRENT I/O FUNCTION 

D.VOUT=4 ;DEVICE TIMEOUT 

D. VPWF=6 ; POWERFAIL RECOVERY 

D. VKRB=10 ;CONTROLLER STATUS CHANGE ENTRY 

D.VUCB=12 UNIT STATUS CHANGE ENTRY 


-IF NB SYSDEF 


D.VINT=14 


- ENDC 


;BEGINNING OF INTERRUPT STUFF 
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EPKDF$ 


EPKDFS 


ERROR MESSAGE BLOCK DEFINITIONS 


=e Se Oe 


-ASECT 


HEADER SUBPACKET 


me MO Me Me Ne 


+-----~----~--------------------- +--+ - - -- - - --- + 
; | SUBPACKET LENGTH IN BYTES | 
; tas SSS SSS SS ea ea Sa tS SSeS + 
; | SUBPACKET FLAGS | 
; Pas SS SSS 33555555555 =—-= ese SS SSS 3S 55 SS 2-5 + 
; | FORMAT IDENTIFICATION | OPERATING SYSTEM CODE | 
; PSS sSesS ise SS32 55S PRaesSrS—S cS SSr SHH SSS + 

; 
: Sa ata ee om tS SHS Ss SSS SS4SS—S2> + 
; | FLAGS | CONTEXT CODE | 
; a a al a te SSS ees Sr SSS SSS se + 
; | ENTRY SEQUENCE | 
; hoe eS Sa SSS Ha SSS eS eee Se SS Se + 
; | ERROR SEQUENCE | 
; tS SS S$553—S5-=--+$+-=-= hast SS SSeS 5 S455 +2 4445 + 
; | ENTRY TYPE SUBCODE | ENTRY TYPE CODE | 
; 4+-------------------~---- +----------------------- + 
; | TIME STAMP | 
; | 
; | | 
; Ceaser SS S55 S4—s5>-—5= tees SoS StS ase SSeS == + 
; | RESERVED | PROCESSOR TYPE | 
; ton rr rrr nee fae enn nr rn rn nr rn ere + 
; | PROCESSOR IDENTIFICATION (URM) | 
H a rrr rte + 

i 

~-=0 

000000 ESHLGH: .BLKW 1 ; SUBPACKET LENGTH IN BYTES 
000002 ESHSBF: .BLKW 1 ; SUBPACKET FLAGS 
- 000004 ESHSYS: .BLKB 1 ; OPERATING SYSTEM CODE 
000005 ESHIDN: .BLKB 1 ; FORMAT IDENTIFICATION 
000006 ESHSID: .BLKB 4 ; OPERATING SYSTEM IDENTIFICATION 
000012 ESHCTX: .BLKB i ; CONTEXT CODE 
000013 ESHFLG: .BLKB 1 ; FLAGS 
000014 ESHENS: .BLKW 1 ; ENTRY SEQUENCE NUMBER 
000016 ESHERS: .BLKW 1 ; ERROR SEQUENCE NUMBER 
000020 ESHENC: ; ENTRY CODE 
000020 ESHTYC: .BLKB id ; ENTRY TYPE CODE 
000021 ESHTYS: .BLKB 1 ; ENTRY TYPE SUBCODE 
000022 ESHTIM: .BLKB 6 ; TIME STAMP 
000030 ESHPTY: .BLKB 1 ; PROCESSOR TYPE 
000031 . BLKB a ; RESERVED 
000032 ESHURM: .BLKW 1 ; PROCESSOR IDENTIFICATION (URM) 
. EVEN 


000034 ESHLEN: LENGTH 


=e 
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=e Te te 
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EPKDF$ (Cont.) 


SUBPACKET FLAGS FOR ESHSBF 


SM.ERR 
SM.HDR 
SM. TSK 
SM.DID 
SM. DOP 
SM. DAC 
SM. DAT 
SM.MBC 
SM.CMD 
SM. ZER 


100000 
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CODES FOR FIELD ESHIDN 


EHSFOR 


FLAGS FOR THE 


ES.INI 
ES. DAT 
ES.LIM 
ES.LOG 


4 


ERROR LOG 


Vou it ow 
~ 

Oo PNF 
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ERROR PACKET 

HEADER SUBPACKET 

TASK SUBPACKET 

DEVICE IDENTIFICATION SUBPACKET 
DEVICE OPERATION SUBPACKET 

DEVICE ACTIVITY SUBPACKET 

DATA SUBPACKET 

22-BIT MASSBUS CONTROLLER PRESENT 
ERROR LOG COMMAND PACKET 

ZERO I/O COUNTS 


CURRENT PACKET FORMAT 


FLAGS BYTE (SERFLA) IN THE EXEC 


ERROR LOG INITIALIZED 
ERROR LOG RECEIVING DATA PACKETS 
ERROR LIMITING ENABLED 
ERROR LOGGING ENABLED 


TYPE AND SUBTYPE CODES FOR FIELDS ESHTYC AND ESHTYS 


SYMBOLS 
SYMBOLS 


ESCCMD 
ESSSTA 
ESSSWI 
ESSAPP 
ESSBAC 
ESSSHO 
ESSCHL 


ESCERR 
ESSDVH 
ESSDVS 
ESSTMO 
ESSUNS 


ESCDVI 
ESSDVI 


ESCDCI 
ESSMOU 
ESSDMO 
ESSRES 
ESSRCT 


ESCCPU 
ESSMEM 
ESSINT 


WITH NAMES ESCXXX ARE TYPE CODES FOR FIELD ESHTYC, 
WITH NAMES ESSXXX ARE SUBTYPE CODES FOR FIELD ESHTYS 


NO PWN F fF 
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ERROR LOG CONTROL 
ERROR LOG STATUS CHANGE 
SWITCH LOGGING FILES 
APPEND FILE 
DECLARE BACKUP FILE 
SHOW 
CHANGE LIMITS 


DEVICE ERRORS 
DEVICE HARD ERROR 
DEVICE SOFT ERROR 
DEVICE INTERRUPT TIMEOUT 
DEVICE UNSOLICITED INTERRUPT 


DEVICE INFORMATION 
DEVICE INFORMATION MESSAGE 


DEVICE CONTROL INFORMATION 
DEVICE MOUNT 
DEVICE DISMOUNT 
DEVICE COUNT RESET 
BLOCK REPLACEMENT 


CPU DETECTED ERRORS 
MEMORY ERROR 
UNEXPECTED INTERRUPT 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


EPKDF$ (Cont.) 


ESCSYS = 6 ; SYSTEM CONTROL INFORMATION 
ESSPWR = i. POWER RECOVERY 
ESCCTL- = 7 ; CONTROL INFORMATION 

ESSTIM = : ae TIME CHANGE 

ESSCRS = 2 4 SYSTEM CRASH 

ESSLOA = 3° 3 DEVICE DRIVER LOAD 
ESSUNL = 4; DEVICE DRIVER UNLOAD 
ESSHRC = a: 4 RECONFIGURATION STATUS CHANGE 
ESSMES = 6.3 MESSAGE 

ESCSDE = 10 ; SOFTWARE DETECTED EVENTS 
ESSABO = 5 ae TASK ABORT 


CODES FOR CONTEXT CODE ENTRY ESHCTX 


=e tse te 


EHSNOR = 1 ; NORMAL ENTRY 
EHSSTA = 2 ; START ENTRY 
EHSCRS = 3 ; CRASH ENTRY 


CODES FOR FLAGS ENTRY ESHFLG 


we MO Ne 


EHSVIR = 1 ; ADDRESSES ARE VIRTUAL 
EHSEXT = 2 ; ADDRESSES ARE EXTENDED 
EHSCOU = 4 ; ERROR COUNTS SUPPLIED 

TASK SUBPACKET 
+------ ----------- -- -- - - - - - - -- - - - - - + 
| TASK SUBPACKET LENGTH | 
+--------—~--~--—------- - ~~ -- - - - - -- - - - - - - - - - + 


+---------------—------- ~~ - ++ + 
| TASK UIC | 
+--------------------------- - - - - - - - ~~ - + 
| TASK TI: DEVICE NAME | 
+--------------------- +-~-------~----~------~---+ + 
| FLAGS | TASK TI: UNIT NUMBER | 
+-~---------------------- +-—------------~---~--~---- + 


“ee Se we Ne Se Me MO MO Me MO Me Ne Me ONO ON 


TASK SUBPACKET LENGTH 
TASK NAME IN RAD50 
TASK UIC 

TI: DEVICE NAME 
TASK TI: UNIT 


000000 ESTLGH: .BLKW 
000002 ESTTSK: .BLKW 
000006 ESTUIC: .~BLKW 
000010 ESTTID: .BLKB 
000012 ESTTIU: .BLKB 
000013 ESTFLG: .BLKB 


PRENUrFNH 
=e me ™O@ Se Me FO 
W 
» 
n 
Rn 


000014 ESTLEN: 


FLAGS FOR ENTRY ESTFLG 


me we Ne 


TASK IS PRIVILEGED 
TERMINAL IS PRIVILEGED 


ETSPRV 
ETSPRI 


nou 
No 
~e Me 
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DEVICE IDENTIFICATION SUBPACKET 


+-—----~------------------------ - + - - - - - - = --- - + 
| DEVICE IDENTIFICATION SUBPACKET LENGTH | 
+—-—------------ ~~ - - - - - - - - - - - + 
| DEVICE MNEMONIC NAME | 
+-~---------------------- +----------------------- + 
| CONTROLLER NUMBER | DEVICE UNIT NUMBER | 
+----------------------- +----------------------- + 
| PHYSICAL SUBUNIT # | PHYSICAL UNIT # | 
4+----------------------- +----------------------- + 
| PHYSICAL DEVICE MNEMONIC (RSX-11M-PLUS ONLY) | 
+----------------------- +--~-------------------- + 
| RESERVED | FLAGS | 
4+-~--------------------- +----------------------- + 


VOLUME NAME OF MOUNTED VOLUME 


=e me "2 Se we NO Te ME MO Me Me NO TO Me NO Ne we TH Te Me 8 MO Me TO Me MO MO MO Ne TO TO Ne NO Me Ne HO TO MO NEO we me te TO 


000000 ESILGH: .BLKW 1 ; DEVICE IDENTIFICATION SUBPACKET LENGTH 
000002 ESILDV: .BLKW a ; DEVICE MNEMONIC NAME 

000004 ESILUN: .BLKB 1 ; DEVICE UNIT NUMBER 

000005 ESIFPCO: .BLKB ui ; CONTROLLER NUMBER 

000006 ESIPUN: .BLKB a ; PHYSICAL UNIT NUMBER 

000007 ESIPSU: .BLKB Ef ; PHYSICAL SUBUNIT NUMBER 
000010 ESIPDV: .BLKW a3 ; PHYSICAL DEVICE MNEMONIC 
000012 ESIFLG: .BLKB i ; FLAGS 

000013 - BLKB 1 ; RESERVED 

000014 ESIVOL: .BLKB 12s 7 VOLUME NAME 

000030 ESIPAK: .BLKB 4 ; PACK IDENTIFICATION 

000034 ESIDEV: ; DEVICE TYPE 

000034 ESIDCL: .BLKW 1 ; DEVICE TYPE CLASS 

000036 ESIDTY: .BLKW 2 ; DEVICE TYPE 

000042 ESIOPR: .BLKW 2 ; I/O OPERATION COUNT LONGWORD 
000046 ESIERS: .BLKB a ; SOFT ERROR COUNT 

000047 ESIERH: .BLKB 1 ; HARD ERROR COUNT 
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BLOCKS TRANSFERRED COUNT 
CYLINDERS CROSSED COUNT 


000050 ESIBLK: .BLKW 

000054 ESICYL: .BLKW 2 
.« EVEN 

000060 ESILEN: ; SUBPACKET LENGTH 


N 


=e Me 


FLAGS FOR FIELD ESIFLG 


=e Te MO 


SUBCONTROLLER DEVICE 
NO UCB EXTENSION, DATA INVALID 


EISSUB 
EILSNUX 


=e se 


af 
2 


DEVICE OPERATION SUBPACKET 


+--~-------------------- -~-- - - - - - - - - - - - - - - - + 
| TASK UIC 
+------------------------------ ------ ----------- + 
| TASK TI: LOGICAL DEVICE MNEMONIC | 
+----------------------- +--------------~-------- + 
! RESERVED | TASK TI: DEVICE UNIT } 
4+----------- = - = 4+----------------------- + 
| I/O FUNCTION CODE | 
+----------------------- 4+—----—------------------ + 
| RESERVED | OPERATION FLAGS 

+----------------------- +----------------------- + 


| TRANSFER OPERATION ADDRESS | 


+---------------~---------------- - ----- - - - ------- + 
| TRANSFER OPERATION BYTE COUNT | 
+-------------------------- -- + - - - - -- + - = - - + - = + 
| CURRENT OPERATION RETRY COUNT | 
+--------------~------~------------ ----- --- ----- == + 


me me MO NO Ne Ge NO MO TO MO MO WO Ne M8 Me Ne HO MO MO TD Me Me MO Me Me MO Ow 


-=0 
000000 ESOLGN: .BLKW 
000002 ESOTSK: .BLKW 
000006 ESOUIC: .BLKW 
000010 ESOTID: .BLKB 
000012 ESOTIU: .BLKB 
000013 
000014 ESOFNC: .BLKW 
000016 ESOFLG: .BLKB 
000017 - BLKB 
000020 ESOADD: .BLKW 
000024 ESOSIZ: .BLKW 
000026 ESORTY: .BLKW 


SUBPACKET LENGTH 

TASK NAME IN RAD50 

TASK UIC 

TASK TI: LOGICAL DEVICE MNEMONIC 
TASK TI: LOGICAL DEVICE UNIT 
RESERVED 

I/O FUNCTION CODE 

OPERATION FLAGS 

RESERVED 

TRANSFER OPERATION ADDRESS 
TRANSFER OPERATION BYTE COUNT 
CURRENT OPERATION RETRY COUNT 


e 
w 
tc 
RK 
ow 
PRN RP RRP PHN rH 


™~e ™e ™e SMe Me Me MO MO SB MO NO NO 


000030 ESOLEN: DEVICE OPERATION SUBPACKET LENGTH 


=e 


FLAGS FOR FIELD ESOFLG 


=e te Ne 


TRANSFER OPERATION 
DMA DEVICE 


EOSTRA 
EOSDMA 


wou 
— 
me te 
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EOSEXT = 4 ; EXTENDED ADDRESSING DEVICE 
EOSPIP = 10 ; DEVICE IS POSITIONING 
; 
; I/O ACTIVITY SUBPACKET 
; 
; Ta a nn nr rrr rrr + 
; | I/O ACTIVITY SUBPACKET LENGTH | 
; Se ee hel teehee eect eeeeeeiaatenteneeteenentetenteeese + 
; 
000000 ESALGH: .BLKW 1 ; SUBPACKET LENGTH 
; 
; I/O ACTIVITY SUBPACKET ENTRY 
; 
; ha rrr + 
; | LOGICAL DEVICE NAME MNEMONIC | 
; +-~-------------~-------- +-----------~------------ + 
; | CONTROLLER NUMBER | LOGICAL DEVICE UNIT | 
; ten rn nr er nnn wr nr ern ee tern nm nr rr nn nr nr reno + 
; | PHYSICAL SUBUNIT # | PHYSICAL UNIT NUMBER | 
H i SES ac a a a toss SSS SS SSeS SSS 5---> + 
; | PHYSICAL DEVICE MNEMONIC (RSX-11M-PLUS ONLY) | 
: toe rr rr nnn SSS SSS S-S SSS —-- = + 
; | TASK TI: LOGICAL UNIT | DEVICE FLAGS | 
: +------------------~----- 4+-----------~----------- + 
: | REQUESTING TASK NAME IN RAD50 | 
‘: | | 
tf 
H ho Se SSS a Se a Se SS SS SSeS + 
; | REQUESTING TASK UIC | 
; Pen a a a a a er rr rn tn ere ener + 
; | TASK TI: LOGICAL DEVICE NAME | 
: rrr rrr rss + 
; | I/O FUNCTION CODE | 
; tw wr nr nr rrr nr er nrnre nee - $a a ee er eee + 
; | RESERVED | FLAGS | 
H +—- eee han nr rr nr nnn nr nr rrr eee + 
; | TRANSFER OPERATION ADDRESS | 
; | | 
: te a a nn rrr rrr rrr + 
; | TRANSFER OPERATION BYTE COUNT | 
H nn rrr rss + 
; 


-=0 
000000 ESALDV: .BLKW 
000002 ESALUN: .BLKB 
000003 ESAPCO: .BLKB 
000004 ESAPUN: .BLKB 
000005 ESAPSU: .BLKB 
000006 ESAPDV: .BLKW 
000010 ESADFG: .BLKB 
000011 ESATIU: .BLKB 
000012 ESATSK: .BLKW 
000016 ESAUIC: .BLKW 
000020 ESATID: .BLKW 
000022 ESAFNC: .BLKW 
000024 ESAFLG: .BLKB 


LOGICAL DEVICE NAME MNEMONIC 
LOGICAL DEVICE UNIT 
CONTROLLER NUMBER 

PHYSICAL UNIT NUMBER 
PHYSICAL SUBUNIT NUMBER 
PHYSICAL DEVICE MNEMONIC 
DEVICE FLAGS 

TASK TI: LOGICAL UNIT 
REQUESTING TASK NAME IN RAD50 
REQUESTING TASK UIC 

TASK TI: LOGICAL DEVICE NAME 
I/O FUNCTION CODE 

FLAGS 


BMRB HRP RP Pe ee 


me ™e MO Me MO NO Ge Ne We Me We WE We 
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000025 
000026 
000032 


000034 


ESAADD: 
ESA31Z: 


ESA LEN: 


=e ™e Se 


FUAGS 


FLAGS 


.- BLKB 1 
- BLKW 2 
.- BLKW i 
» EVEN 


FOR FIELD ESADFG 


EASSUB 
EASNUX 


FOR FIELD ESAFLG 


EASTRA 
EASDMA 
FASEXT 
EASPIP 


oui 


-PSECT 


1 
2 


OfhND Fe 


we “ee Me 


™e 


=e me 


™e Se TO MO 


SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


RESERVED 
TRANSFER OPERATION ADDRESS 
TRANSFER OPERATION BYTE COUNT 


SUBPACKET ENTRY LENGTH 


SUBCONTROLLER DEVICE 
NO UCB EXTENSION, DATA INVALID 


TRANSFER OPERATION 

DMA DEVICE 

DEVICE HAS EXTENDED ADDRESSING 
DEVICE IS POSITIONING 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 
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F11DFS$ 


re OYSDEF 


VOLUME CONTROL BLOCK 


F11DF$ 


-ASECT 
-=0 
000000 V.TRCT: .BLKW 1 ; TRANSACTION COUNT 
000002 V.TYPE: .~BLKB i: ; VOLUME TYPE DESCRIPTOR 
VT.SL1= 1 ; FILES-11 STRUCTURE LEVEL 1 
VT.ANS= 10 ; ANSI LABELED TAPE 
VT.UNL= 11 ; UNLABELED TAPE 
000003 V.VCHA: .BLKB 1 ; VOLUME CHARACTERISTICS 
VC.SLK= 1 ; CLEAR VOLUME VALID ON DISMOUNT 
VC.HLK= 2 ; UNLOAD THE VOLUME ON DISMOUNT 
VC.DEA= 4 ; DEALLOCATE THE VOLUME ON DISMOUNT 
VC.PUB= 10 ; SET (CLEAR) US.PUB ON DISMOUNT 
000004 V.LABL: .BLKB 14 ; VOLUME LABEL (ASCIT) 
000020 V.PKSR: .BLKW 2 ; PACK SERIAL NUMBER FOR ERROR LOGGING 
000024 V.SLEN: ; LENGTH OF SHORT VCB 
000024 V.IFWI: .BLKW 1 ; INDEX FILE WINDOW 
000026 V.FCB: .BLKW 2 ; FILE CONTROL BLOCK LIST HEAD 
000032 V.IBLB: .BLKB A ; INDEX BIT MAP 1ST LBN HIGH BYTE 
000033 V.IBSZ: .BLKB 1 ; INDEX BIT MAP SIZE IN BLOCKS 
000034 - BLKW 1 ; INDEX BITMAP 1ST LBN LOW BITS 
000036 V.FMAX: .BLKW aE ; MAX NO. OF FILES ON VOLUME 
000040 V.WISZ: .BLKB ui ; DEFAULT SIZE OF WINDOW IN RTRV PTRS 
; VALUE IS < 128. 
000041 V.SBCL: .BLKB 1 ; STORAGE BIT MAP CLUSTER FACTOR 
000042 V.SBSZ: .BLKW J ; STORAGE BIT MAP SIZE IN BLOCKS 
000044 V.SBLB: .BLKB 1 ; STORAGE BIT MAP 1ST LBN HIGH BYTE 
000045 V.FIEX: .BLKB 1 ; DEFAULT FILE EXTEND SIZE 
000046 - BLKW 1 ; STORAGE BIT MAP 1ST LBN LOW BITS 
000050 V.VOWN: .BLKW al ; VOLUME OWNER'S UIC 
000052 V.VPRO: .BLKW 1 7; VOLUME PROTECTION 
000054 V.FPRO: .BLKW 1 ; VOLUME DEFAULT FILE PROTECTION 
000056 V.FRBK: .BLKB 1 ; NUMBER OF FREE BLOCKS ON VOLUME HIGH BYTE 
000057 V.LRUC: .BLKB 1 ; COUNT OF AVAILABLE LRU SLOTS IN FCB LIST 
000060 - BLKW 1 ; NUMBER OF FREE BLOCKS ON VOLUME LOW BITS 
000062 V.STS: .BLKB 1 ; VOL STATUS BYTE, CONTAINING THE FOLLOWING 
VS.IFW= 1 ; INDEX FILE IS WRITE ACCESSED 
VS.BMW= 2 ; STORAGE BITMAP FILE IS WRITE ACCESSED 
000063 V.FFNU: .BLKB J ; FIRST FREE INDEX FILE BITMAP BLOCK 
000064 V.EXT: .BLKW 1 ; POINTER TO VCB EXTENSION 
000066 V.LGTH: ; SIZE IN BYTES OF VCB 
; MOUNT LIST ENTRY 
’ 
; EACH ENTRY ALLOWS ACCESS TO A SPECIFIED USER FOR A NON-PUB DEVICE 
c 
; TO ALLOW EXPANSION, ONLY THE ONLY TYPE CODE DEFINED IS "1" FOR 
; DEVICE ACCESS BLOCKS 
eASECT 
-=0 
000000 M.LNK: .BLKW 1 ; LINK WORD 
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000002 


000003 
000004 
000006 


000010 


000000 
000002 
000004 
000006 
000007 
000010 
000012 
000014 
000015 
000016 


000022 


000026 
000032 
000033 


000012 


000034 
000034 
000035 


000036 
000040 
000042 
000044 
000050 
000052 


000054 


000000 


M.TYPE: 
MT.MLS= 
M.ACC: 
M.DEV: 
M.TI: 


M.LEN: 


me Ms Ne 


-=0 

F.LINK: 
F.FNUM: 
F.FSEQ: 


F.FSON: 
F.FOWN: 
F.FPRO: 
F.UCHA: 
F.SCHA: 
F.HDLB: 


F.LBN: 


PeOEZE? 
F.NACS: 
F.NLCK: 


S.STBK=. 


F.STAT: 
F.NWAC: 


FC.WAC= 
FC.DIR= 
FC.CEF= 
FC. FCO= 
F.DREF: 
F.DRNM: 
F.FEXT: 
F.EFVBN: 
F.LKL: 

F.WIN: 


F.LGTH: 


; 
+ WINDOW 
; 


.- BLKB 
1 

- BLKB 
- BLKW 
- BLKW 


eASECT 


- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKW 


- BLKW 


- BLKW 
- BLKB 
- BLKB 


-F. LBN 


.- BLKB 
.-BLKB 
100000 
40000 
20000 
10000 
- BLKW 
.- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 


~ASECT 


re 


FILE CONTROL BLOCK 


Oe 


nN) 


bh be 


PRO HH 


™e Me Me MO ME 


me Ne SO MO Me MO Me Me NO Ne 


=e we MO Me MO 


=e 


me me MO Me Ne MO TO MO TE NO Me MO Ne 


TYPE OF ENTRY 

MOUNTED VOLUME USER ACCESS LIST 
NUMBER OF ACCESSES 

DEVICE UCB 
ACCESSOR TI: UCB 


LENGTH OF ENTRY 


FCB CHAIN POINTER 

FILE NUMBER 

FILE SEQUENCE NUMBER 

NOT USED 

FILE SEGMENT NUMBER 

FILE OWNER'S UIC 

FILE PROTECTION CODE 

USER CONTROLLED CHARACTERISTICS 
SYSTEM CONTROLLED CHARACTERISTICS 
FILE HEADER LOGICAL BLOCK NUMBER 


BEGINNING OF STATISTICS BLOCK 

LBN OF VIRTUAL BLOCK 1 IF CONTIGUOUS 
0 IF NON CONTIGUOUS 

SIZE OF FILE IN BLOCKS 

NO. OF ACCESSES 

NO. OF LOCKS 


SIZE OF STATISTICS BLOCK 


FCB STATUS WORD 

NUMBER OF WRITE ACCESSORS 

STATUS BITS FOR FCB CONSISTING OF 
SET IF FILE ACCESSED FOR WRITE 

SET IF FCB IS IN DIRECTORY LRU 

SET IF DIRECTORY EOF NEEDS UPDATING 


SET IF TRYING TO FORCE DIRECTORY CONTIG 


DIRECTORY EOF BLOCK NUMBER 

1ST WORD OF DIRECTORY NAME 

POINTER TO EXTENSION FCB 

STARTING VBN OF THIS FILE SEGMENT 
POINTER TO LOCKED BLOCK LIST FOR FILE 
WINDOW BLOCK LIST FOR THIS FILE 


SIZE IN BYTES OF FCB 


NUMBER OF ACTIVE MAPPING POINTERS 
WHEN NO SECONDARY POOL 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 
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BLOCK SIZE OF SECONDARY POOL SEGMENT 
WHEN SECONDARY POOL 

LOW BYTE = # OF MAP ENTRIES ACTIVE 
HIGH BYTE CONSISTS OF CONTROL BITS 
READ VIRTUAL BLOCK ALLOWED IF SET 

WRITE VIRTUAL BLOCK ALLOWED IF SET 
EXTEND ALLOWED IF SET 

SET IF LOCKED AGAINST SHARED ACCESS 
SET IF DEACCESS LOCK ENABLED 

WINDOW TURN PENDING BIT 

SET IF MANUAL UNLOCK DESIRED 

DATA CHECK ALL WRITES TO FILE 

COUNT OF I/O THROUGH THIS WINDOW 
RESERVED 

FILE CONTROL BLOCK ADDRESS 

POINTER TO LIST OF USERS LOCKED BLOCKS 
WINDOW BLOCK LIST LINK WORD 


000000 W.BLKS: 
000000 W.CTL: .BLKW 1 


WI.RDV= 400 
WI.WRV= 1000 
WI.EXT= 2000 
WI.LCK= 4000 
WI.DLK= 10000 
WI.PND= 20000 
WI.EXL= 40000 
WI.WCK= 100000 
000002 W.IOC: .BLKB 
000003 - BLKB 
000004 W.FCB: .BLKW 
000006 W.LKL: .BLKW 
000010 W.WIN: .BLKW 


me Me Me MO MO Me Me Me Me MO TO TO MO we MO Be TO 


Ree ee 


-IF NB SYSDEF 


=e 


IF SYSDEF SPECIFIED IN CALL 


-IF NDF PSSWND ; IF SECONDARY POOL WINDOWS NOT ALLOWED 


NON-SECONDARY POOL WINDOW BLOCK 
IF SECONDARY POOL WINDOWS ARE NOT ENABLED, THE WINDOW BLOCK 
CONTAINS THE CONTROL INFORMATION AND RETRIEVAL POINTERS. 


HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 

DEF LABEL WITH ODD ADDR TO CATCH BAD REFS 
SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 


-VBN: .BLKB 1 

-MAP: 

-WISZ: .BLKB 1 
- BLKW 1 


= = Ss me 6% 68 TO 


=e %O8 MO Me MO 


W.RTRV: 


Ler 


=e 


IF WINDOWS IN SECONDARY POOL 


SECONDARY POOL WINDOW CONTROL AND MAPPING BLOCK 
IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, LUTN2 POINTS 
TO A CONTROL BLOCK IN SYSTEM POOL WHICH CONTAINS THE 
FOLLOWING CONTROL FIELDS AND THE MAPPING INFORMATION 
FOR THE SECONDARY POOL WINDOW. 


a mea ™e MO NG Te MO 


-MAP: .BLKW J ; ADDR TO THE MAPPING PTRS IN SECONDARY POOL 


SECONDARY POOL WINDOW 
IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, THE RETRIEVAL 
POINTERS ARE MAINTAINED IN SECONDARY POOL IN THE FOLLOWING 
FORMAT. 


e me ™e TO NS TO ME 


ASSUME W.CTL,O 

-BLKB 1 7 NUMBER OF ACTIVE MAPPING POINTERS 
W.USE: .BLKB a ; STATUS OF BLOCK 
W.VBN: .BLKB 1 ; HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 
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SIZE IN RTRV PTRS OF WINDOW (7 BITS) 
LOW ORDER WORD OF 1ST VBN MAPPED 
OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 


W.WISZ: .BLKB 
- BLKW 1 
W.RTRV: 


he 


me ™e NO 


-ENDC ;PSSWND END SECONDARY POOL WINDOW CONDITIONAL 


=e 


END SYSDEF CONDITIONAL 


=e 


e-ENDC ;SYSDEF 


LOCKED BLOCK LIST NODE 


me “oe te 


eASECT 


LINK TO NEXT NODE IN LIST 

POINTER TO WINDOW FOR FIRST ENTRY 
HIGH ORDER VBN BYTE 

COUNT FOR ENTRY 

LOW ORDER VBN 


000000 L.LNK: .BLKW 
000002 L.WIl: .BLKW 
000004 L.VB1l: .BLKB 
000005 L.CNT: .BLKB 
000006 - BLKW 


a 
me Se Se Me MO 


000010 L.LKSZ: 


- PSECT 
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000000 
000002 
000004 
000005 
000006 
000010 
000012 
000014 
000016 
000020 
000022 
000024 
000026 
000030 
000032 
000034 
000036 
000040 
000042 
000044 
000046 
000050 
000052 
000054 
000056 
000060 
000061 
000062 
000064 
000065 
000066 
000072 
000074 
000076 


000000 
000002 
000004 
000006 


HDRDFS 


; 
; TASK HEADER OFFSET DEFINITIONS 


HDRDFS$ 


STACK POINTER 


;HEADER LENGTH IN BYTES 
;SUPERVISOR D SPACE OVERMAP MASK 
;USER D SPACE OVERMAP MASK 


TASK UIC 

TASK UIC 

PROCESSOR STATUS WORD (PS) 
PROGRAM COUNTER (PC) 

STACK POINTER (SP) 

VECTOR ADDRESS 

VECTOR LENGTH 


;TASK SST VECTOR ADDRESS 

;TASK SST VECTOR LENGTH 

; POWER FAIL AST CONTROL BLOCK ADDRESS 
;FLOATING POINT AST CONTROL BLOCK ADDRESS 


AST CONTROL BLOCK ADDRESS 


; EVENT FLAG ADDRESS SAVE ADDRESS 


TO FLOATING POINT/EAE SAVE AREA 
TO NUMBER OF WINDOW BLOCKS 


;TASK DIRECTIVE STATUS WORD 
;FCS IMPURE POINTER 


IMPURE POINTER 
IMPURE POINTER 


;WORK AREA EXTENSION VECTOR POINTER 
;PRIORITY DIFFERENCE FOR SWAPPING 


M>.ILBOX LUN 


BY REFERENCE AST CONTROL BLOCK ADDR 


BY X25 SOFTWARE 


75 RESERVED BYTES 


TO HEADER GUARD WORD 


;NUMBER OF LUN'S 


.eASECT 
H.CSP: .BLKW 1 ; CURRENT 
H.HDLN: .BLKW 1 
H.SMAP: .BLKB a 
H.DMAP: .BLKB 1 

- BLKW 1 ; RESERVED 
H.CUIC: .~BLKW 1 ; CURRENT 
H.DUIC: .BLKW i ; DEFAULT 
H.IPS: .BLKW 1 ; INITIAL 
H.IPC: .BLKW 1 ; INITIAL 
H.ISP: .BLKW 1 ; INITIAL 
H.ODVA: .~BLKW 1 ;ODT SST 
H.ODVL: .~BLKW A ;ODT SST 
H.TKVA: .~BLKW il 
H.TKVL: .~BLKW 1 
H.PFVA: .BLKW 1 
H.FPVA: .~BLKW 1 
H.RCVA: .BLKW 1 ; RECIEVE 
H.EFSV: .BLKW di 
H.FPSA: .BLKW 1 ; POINTER 
H.WND: .BLKW 1 ; POINTER 
H.DSW: .BLKW J} 
H.FCS: .BLKW 1 
H.FORT: .BLKW 1 ; FORTRAN 
H.OVLY: .~BLKW 1 ; OVERLAY 
H.VEXT: .~BLKW bi 
H.SPRI: .BLKB 1 
H.NML: .BLKB 1 ; NETWORK 
H.RRVA: .BLKW 1 ; RECEIVE 
H.X25: .BLKB 1 ;FOR USE 

- BLKB a 

- BLKW 2 ; 
H.GARD: .BLKW 1 ; POINTER 
H.NLUN: .~BLKW a 
H.LUN: .BLKW 2 


;START OF LOGICAL UNIT TABLE 


LENGTH OF FLOATING POINT SAVE AREA 


; 
; 
H.FPSL=25.¥*2 


=e 


W.BPCB: .~BLKW 1 
W.BLVR: .BLKW L 
W.BHVR: .~BLKW 1 
W.BATT: .~BLKW 1 


; PARTITION CONTROL BLOCK ADDRESS 
;LOW VIRTUAL ADDRESS LIMIT 

;HIGH VIRTUAL ADDRESS LIMIT 
;ADDRESS OF ATTACHMENT DESCRIPTOR 
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000010 W.BSIZ: .BLKW 1 ;SIZE OF WINDOW IN 32W BLOCKS 

000012 W.BOFF: .BLKW 1 ; PHYSICAL MEMORY OFFSET IN 32W BLOCKS 
000014 W.BFPD: .BLKB 1 ;FIRST PDR ADDRESS 

000015 W.BNPD: .BLKB 1 ;NUMBER OF PDR'S TO MAP 

000016 W.BLPD: .BLKW 1 ;CONTENTS OF LAST PDR 

000020 W.BI.GH: ;LENGTH OF WINDOW DESCRIPTOR 


BIT DEFINITION FOR W.BLPD 


e ™e %e 


‘ 
WB.NBP=20 ;CACHE BYPASS IS NOT DESIRED FOR THIS WINDOW 
WB.EPS=40 ;ALWAYS BYPASS THE CACHE FOR THIS WINDOW 

- PSECT 
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HWDDF$ 
HWDDF$ ,,SYSDEF 
? 
; MACROS FOR DEFINING MAPPING REGISTER DEFINITIONS 
a 
-MACRO CRESET NAM,ADDR 
$$$=0 
.REPT Bs 
CRENAM NAM,ADDR+<$$$*2>,\$S$$ 
$$$=S$$$+1 
- ENDR 
. ENDM 
-MACRO CRENAM NAM,ADDR,N 
'NAM' 'N'==ADDR 
. ENDM 
; 
; HARDWARE REGISTER ADDRESSES AND STATUS CODES 
MPCSR=177746 ;ADDRESS OF PDP-11/70 MEMORY PARITY REGISTER 
MPAR=172100 ;ADDRESS OF FIRST MEMORY PARITY REGISTER 
PIRQ=177772 ; PROGRAMMED INTERRUPT REQUEST REGISTER 
PRO=0 ;PROCESSOR PRIORITY O 
PR1=40 ;PROCESSOR PRIORITY 1 
PR4=200 :PROCESSOR PRIORITY 4 
PR5=240 ;PROCESSOR PRIORITY 5 
PR6=300 :PROCESSOR PRIORITY 6 
PR7=340 sPROCESSOR PRIORITY 7 
PS=177776 ; PROCESSOR STATUS WORD 
SWR=177570 ;CONSOLE SWITCH AND DISPLAY REGISTER 
TPS=177564 s;CONSOLE TERMINAL PRINTER STATUS REGISTER 


EXTENDED ARITHMETIC ELEMENT REGISTERS 


me “ee MO 


-IF DF ESSEAE 


AC=177302 ; ACCUMULATOR 
MQ=177304 ;MULTIPLIER-QUOTIENT 
SC=177310 ;SHIFT COUNT 

- ENDC 


MEMORY MANAGEMENT HARDWARE REGISTERS AND STATUS CODES 


=e te we 


-IF NB B 

CRESET KINAR,172340 ;KERNEL I PAR'S 
CRESET KINDR,172300 ;KERNEL I PDR'S 
CRESET KDSAR,172360 ;KERNEL D PAR'S 
CRESET KDSDR,172320 ;KERNEL D PDR'S 
CRESET SISAR,172240 ;SUPERVISOR I PAR'S 
CRESET SISDR,172200 ;SUPERVISOR I PDR'S 
CRESET SDSAR,172260 ;SUPERVISOR D PAR'S 
CRESET. SDSDR,172220 ;SUPERVISOR D PDR'S 
CRESET UINAR,177640 ;USER I PAR'S 
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HWDDFS$ (Cont.) 


CRESET 
CRESET 
CRESET 
- ENDC 

-IF NB 
ie DE 


CRESET 
CRESET 


oLEF 


CRESET 
CRESET 


- ENDC 


LF DF 


CRESET 
CRESET 


Pp el 


CRESET 
CRESET 


- ENDC 


- ENDC 
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UINDR, 177600 ;USER I PDR'S 
UDSAR, 177660 ;USER D PAR'S 
UDSDR,177620 ;USER D PDR'S 
SYSDEF 

KSSDAS 

KISAR, 172360 ;KERNEL D PAR'S 
KISDR,172320 ;KERNEL D PDR'S 
KISAR,172340 ;KERNEL I PAR'S 
KISDR,172300 ;KERNEL I PDR'S 
USSDAS 

UISAR, 177660 ;USER D PAR'S 
UISDR,177620 ;USER D PDR'S 

; DF USSDAS 

UISAR,177640 ;USER I PAR‘S 
UISDR,177600 ;USER I PDR'S 


: DF USSDAS 


UBMPR=170200 
CMODE=1 40000 
PMODE=30000 
CSMODE=40000 
PSMODE=10000 
SRO=177572 
SR3=172516 
CPUERR=177766 
MEMERR=177744 
MEMCTL=177746 


e ®e we 


FE. EXT=1 
FE.MUP=2 
FE. EXV=4 
FE. DRV=10 
FE. PLA=20 
FE.CAL=40 
FE. PKT=100 
FE. EXP=200 
FE.LSI=400 
FE. OFF=1000 
FE. FDT=2000 


;UNIBUS MAPPING REGISTER 0 

;CURRENT MODE FIELD OF PS WORD 

;PREVIOUS MODE FIELD OF PS WORD 

;CURRENT MODE = SUPERVISOR PS WORD BITS 
;PREVIOUS MODE = SUPERVISOR PS WORD BITS 
;SEGMENT STATUS REGISTER 0 

;SEGMENT STATUS REGISTER 3 

;CPU ERROR REGISTER 

;MEMORY SYSTEM ERROR REGISTER 

*MEMORY CONTROL REGISTER 


FEATURE SYMBOL DEFINITIONS 


;22-BIT EXTENDED MEMORY SUPPORT 
;MULTI-USER PROTECTION SUPPORT 
;EXECUTIVE IS SUPPORTED TO 20K 

; LOADABLE DRIVER SUPPORT 

;PLAS SUPPORT 

DYNAMIC CHECKPOINT SPACE ALLOCATION 
;PREALLOCATION OF I/O PACKETS 
EXTEND TASK DIRECTIVE SUPPORTED 

; PROCESSOR IS AN LSI-11 

; PARENT/OFFSPRING TASKING SUPPORTED 
;FULL DUPLEX TERMINAL DRIVER SUPPORTED 
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FE.X25=4000 
FE.DYM=10000 
FE.CEX=20000 
FE.MXT=40000 
FE.NLG=100000 


oe me Se 


‘ 

F2.DAS=1 
F2.LIB=2 
F2.MP=4 
F2.EVT=10 
F2.ACN=20 
F2.SDW=40 
F2.POL=100 
F2.WND=200 
F2.DPR=400 
F2.IRR=1000 
F2.GGF=2000 
F2.RAS=4000 
F2.AHR=10000 
F2.RBN=20000 
F2.S5WP=40000 


F2.S5TP=100000 


oe *e Me 


F3.CRA=1 
F3.XCR=2 
F3.EIS=4 
F3.STM=10 
F3.UDS=20 
F3.PRO=40 
F3.XHR=100 
F3.AST=200 
F3.11S=400 
F3.CLI=1000 
F3.TCM=2000 
F3.PMN=4000 
F3.WAT=10000 
F3.RLK=20000 
F3.SHF=40000 


Fi]~e se se 


4.CXD=1 


F.UBM=1 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


HWDDFS$ (Cont.) 


7X.25 CEX IS LOADED 

; DYNAMIC MEMORY ALLOCATION SUPPORTED 
;COM EXEC IS LOADED 

;MCR EXIT AFTER EACH COMMAND MODE 
;LOGINS DISABLED - MULTI-USER SUPPORT 


FEATURE MASK DEFINITIONS (SECOND WORD) 


;KERNEL DATA SPACE SUPPORTED 

;SUPERVISOR MODE LIBRARIES SUPPORTED 
SYSTEM SUPPORTS MULTIPROCESSING 

;SYSTEM SUPPORTS EVENT TRACE FEATURE 
7SYSTEM SUPPORTS CPU ACCOUNTING 

;SYSTEM SUPPORTS SHADOW RECORDING 

7;SYSTEM SUPPORTS SECONDARY POOLS 

;SYSTEM SUPPORTS SECONDARY POOL FILE WINDOWS 
7;SYSTEM HAS A SEPARATE DIRECTIVE PARTITION 
; INSTALL, RUN, AND REMOVE SUPPORT 

;GROUP GLOBAL EVENT FLAG SUPPORT 
;RECEIVE/SEND DATA PACKET SUPPORT 

;ALT. HEADER REFRESH AREA SUPPORT 

;ROUND ROBIN SCHEDULING SUPPORT 

;EXECUTIVE LEVEL DISK SWAPPING SUPPORT 
;EVENT FLAG MASK IS IN THE TCB(1=YES) 


THIRD FEATURE MASK SYMBOL DEFINITIONS 


;SYSTEM SPONTANEOUSLY CRASHED (1=YES) 
;SYSTEM CRASHED FROM XDT (1=YES) 

;SYSTEM REQUIRES EXTENDED INSTRUCTION SET 
7;SYSTEM HAS SET SYSTEM TIME DIRECTIVE 
*SYSTEM SUPPORTS USER DATA SPACE 

;SYSTEM SUPPORTS SEC. POOL PROTO TCBS 
;SYSTEM SUPPORTS EXTERNAL TASK HEADERS 
;SYSTEM HAS AST SUPPORT 

7RSX-11S SYSTEM 

;MULTIPLE CLI SUPPORT 

7;SYSTEM HAS SEPARATE TERMINAL DRIVER POOL 
*;SYSTEM SUPPORTS POOL MONITORING 

7;SYSTEM HAS WATCHDOG TIMER SUPPORT 
*;SYSTEM SUPPORTS RMS RECORD LOCKING 
;SYSTEM SUPPORTS SHUFFLER TASK 


FOURTH FEATURE MASK BITS 


7COMM EXEC IS DEALLOCATED (NON-I/D ONLY) 


HARDWARE FEATURE MASK BIT DEFINITIONS 


HF.CIS,HF.FPP DEFINED AS SIGN BITS FOR RUN TIME SPEED 


;PROCESSOR HAS A UNIBUS MAP (1=YES) 
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HWDDFS$ (Cont.) 


HF. EIS=2 ;PROCESSOR HAS EXTENDED INSTRUCION SET 
HF.CIS=200 ;PROCESSOR SUPPORTS COMMERCIAL INST SET 
HF. FPP=100000 ; (1=PROC. HAS NO FLOATING POINT UNIT) 


SYSGEN FEATURE SELECTIONS MASK. THIS IS INTENDED TO RECORD IN A 
BIT MASK THE CHOICES THE USER HAS MADE AT SYSGEN TIME. FEATURES 
WILL BE LISTED HERE WHEN THEY ARE BEING RECORDED FOR OUR 
INFORMATIONAL PURPOSES ONLY. THEY CANNOT BE TESTED LIKE BITS IN 
THE FEATURE MASK SINCE THIS ONLY EXISTS IN THE RSX11M.STB FILE. 
NO BITS IN MEMORY ARE USED. THEY ARE ONLY INTENDED TO BE PRINTED 
FROM THE STB FILE BY CDA. 


~e me Me Me ME Se Me Be 


; 
SF.STD=1 ;STANDARD EXEC SELECTED 
SF.RL2=2 ;SYSTEM IS FROM RLO2 KIT 


MULTIPROCESSOR STATUS TABLE DEFINITIONS (TEMPORARY) 


e =e me 


‘ 

MP.CRH=100000 ;CRASH PROCESSOR IMMEDIATELY 

MP. PWF=40000 ; POWERFAIL ON ONE CPU 

MP.RSM=20000 ;RESET INTERRUPT MASKS 

MP.NOP=10000 ;NOP FUNCTION FOR TRANSMISSION CHECK 
MP.STP=4 ;STOP PROCESSOR IN ORDERLY FASHION 
MP.INT=7777 ;BIC MASK FOR INTERRUPT LVL FUNCTIONS 
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000000 
000002 
000006 
000007 
000010 
000012 
000012 
000014 
000016 
000020 
000022 
000024 
000026 


000030 
000032 
000044 


000046 
000050 


=e sme Me 


-=0 

X.LNK: 
X.JSR: 
X.PSW: 


X. ISR: 
X. FORK: 


X.REL: 
X.DSTI: 
X.TCB: 


X.AST: 
X.VEC: 


X.VPC: 
X. LEN: 


ITBDFS 


»MCALL 
PKTDFS 


~ASECT 


- BLKW 
JSR 

- BLKB 
- BLKB 
- BLKW 


- BLKW 
- BLKW 
- BLKW 
- BLKW 
.- BLKW 
- BLKW 
- BLKW 


-IF NB 
- BLKW 
.- BLKB 
. BLKW 


- BLKW 


- ENDC 


-PSECT 


1 e SYSDEF 


PKTDFS 


SYSDEF 
a 
A. PRM 
1 


AE 


me Me Me MO NO MO MO NE Me MO MO WS TWO 


me MO we MO Ne NO 
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INTERRUPT TRANSFER BLOCK (ITB) OFFSET DEFINITIONS 


DEFINE AST BLOCK OFFSETS 


LINK WORD FOR ITB LIST STARTING IN TCB 
CALL SINTSC 

LOW BYTE OF PSW FOR ISR 
UNUSED 

ISR ENTRY POINT (APR5 MAPPING) 
FORK BLOCK 

THREAD WORD 

FORK PC 

SAVED R5 

SAVED R4 

RELOCATION BASE FOR APR5 
ADDRESS OF DIS.INT. ROUTINE 
TCB ADDRESS OF OWNING TASK 


A.DQSR FOR AST BLOCK 

AST BLOCK 

VECTOR ADDRESS (IF AST SUPPORT, 

THIS IS FIRST AND ONLY AST PARAMETER) 
SAVED VECTOR PC 

LENGTH IN BYTES OF ITB 
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KRBDF$ 


LETT TO 
L7TTIT2 
177773 
177774 
LILTIS 
177776 
000000 


000002 
000004 
000005 
000006 
000010 
000014 
000016 


177754 
177760 


177776 


000000 


KRBDFS$ 


CONTROLLER REQUEST BLOCK (KRB) 


THE CONTROLLER REQUEST BLOCK DEFINES THE ENVIRONMENT OF A DEVICE 
CONTROLLER. EXACTLY ONE KRB EXISTS FOR EVERY DEVICE CONTROLLER 
IN AN RSX-11M+ SYSTEM. THE KRB CONTAINS CERTAIN DEVICE STATUS 
INCLUDING THE CSR AND VECTOR ADDRESS FOR THE CONTROLLER. 


Ty ee ey eT ee eT eT 


-ASECT 
-=177770 
K.PRM: .BLKW 1 ;DEVICE DEPENDANT PARAMETER WORD 
K.PRI: .BLKB L ;CONTROLLER PRIORITY 
K.VCT: .BLKB ng ; INTERRUPT VECTOR ADDRESS 
K.CON: .BLKB be CONTROLLER INDEX WITHIN THE SYSTEM 
K.IOC: .BLKB L ; CONTROLLER I/O COUNT 
K.STS: .BLKW 1 ;CONTROLLER STATUS 
K.CSR: .BLKW ul ;ADDRESS OF CONTROL STATUS REGISTER 
; NOTE: K.CSR MUST BE THE ZERO OFFSET! 
K.OFF: .BLKW 1 ;OFFSET TO UCB/UMR/RHBAE TABLE 
K.HPU: .BLKB 1 ;HIGHEST PHYSICAL UNIT NUMBER 
- BLKB 1 ; UNUSED BYTE 
K.OWN: .BLKW al ;OWNER OF CONTROLLER 
K. CRO: - BLKW 2 ;CONTROLLER REQUEST QUEUE 
K.URM: .BLKW 1 ;CONTROLLER UNIBUS RUN MASK 
K.FRK: - BLKW 1 ;POSSIBLE KRB FORK BLOCK 


OFFSETS FOR THE KRB EXTENSION REACHED BY ADDING (K.OFF) TO 
THE STARTING ADDRESS OF THE KRB. 


A eT et eT 


; DEFINE OFFSETS IN SCB/KRB FOR DISK MSCP CONTROLLERS 


ry 
’ 


-=-20. 

KE.UMH: .BLKW 2 ;LIST HEAD FOR UMR WAITING ASSIGNMENT BLK(S) 

KE.UMC: .~BLKW ii ;COUNT OF AVAILABLE UMR WAITING ASSIGNMENT 
;BLOCK (S) 

.=177776 


KE.RHB: .~BLKW 1 ;OFFSET TO RHBAE REGISTER (IF ANY) 


; WHEN ONE ADDS (K.OFF) TO THE KRB ADDRESS, IT YIELDS AN ADDRESS 

; WHICH POINTS TO HERE. 

KE.UCB: .~BLKW 1 ;OFFSET TO UCB TABLE (IF KS.UCB SET) 
-PSECT 

; 

; CONTROLLER REQUEST BLOCK (KRB) STATUS BIT DEFINITIONS 

KS.OFL=1 ;CONTROLLER OFFLINE (1=YES) 

KS .MOF=2 ;CONTROLLER MARKED FOR OFFLINE (1=YES) 
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177762 
177763 
177764 
177765 
177766 
177770 
177772 
177774 
177775 
177776 


177774 
177775 
177776 
000000 


000002 
000004 
000010 
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KS.UOP=4 ;SUPPORTS OVERLAPPED OPERATION (1=YES) 

KS .MBC=10 ;DEVICE IS MASSBUS CONTROLLER (1=YES) 
KS.SDX=20 ;SEEKS ALLOWED DURING DATA XFERS (1=YES) 

KS. POE=40 ;PARALLEL OPERATION ENABLED (1=YES) 

KS .UCB=100 ;UCB TABLE PRESENT (1=YES) 

KS .DIP=200 ;DATA TRANSFER IN PROGRESS (1=YES) 

KS. PDF=400 ;PRIVILEGED DIAGNOSTIC FUNCTIONS ONLY(1=YES) 


KS. EXT=1000 
KS.SLO=2000 


;EXTENDED 22-BIT UNIBUS CONTROLLER (1=YES) 
;CONTROLLER IS SLOW COMING ONLINE (1=YES) 


; 
; DEFINE THE CONTIGUOUS SCB OFFSETS 


° 
’ 


~-ASECT 
-=177762 
S.PRI: .BLKB L ;CONTROLLER PRIORITY 
S.VCT: .BLKB 1 7 INTERRUPT VECTOR ADDRESS 
S.CON: .BLKB ai ;CONTROLLER INDEX 
- BLKB 1 
- BLKW 1 
S.CSR: .BLKW 1 CONTROL AND STATUS REGISTER 
- BLKW 1 
- BLKB 1 
- BLKB i 
S.OWN: .BLKW 1 ;DISTRIBUTED CNTBL 


SUBCONTROLLER REQUEST BLOCK (KRB1) 


THE SUBCONTROLLER REQUEST BLOCK DEFINES THE ENVIRONMENT OF A 
DEVICE SUBCONTROLLER. EXACTLY ONE KRB1 EXISTS FOR EVERY DEVICE 
SUBCONTROLLER IN AN RSX-11M+ SYSTEM. 


° 
‘ 
° 
c 
° 
e 
. 
f 
e 
f 
e 
td 


e 
e 


-ASECT 

~=-4 

K1.CON: .BLKB 1 ; SUBCONTROLLER INDEX WITHIN THE SYSTEM 
.- BLKB J ;UNUSED BYTE 

K1.STS: .BLKW ul ;SUBCONTROLLER STATUS 

K1.MAS: .~BLKW 1 ;UCB ADDRESS OF THE MASTER UNIT 

; NOTE: K1.MAS MUST BE THE ZERO OFFSET 

K1.OWN: .BLKW 1 ; OWNER OF SUBCONTROLLER 

K1.CRQ: .~BLKW 2 ;SUBCONTROLLER REQUEST QUEUE 

Ki UCBs ;START OF THE UCB TABLE (IF ANY) 
-PSECT 
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LCBDF$ 


000000 
000002 
000004 
000005 
000006 
000010 
000012 


LCBDF$ 


me Me 


LOGICAL ASSIGNMENT CONTROL BLOCK 


THE LOGICAL ASSIGNMENT CONTROL BLOCK (LCB) IS USED TO ASSOCIATE A 
LOGICAL NAME WITH A PHYSICAL DEVICE UNIT. LCB'S ARE LINKED 
TOGETHER TO FORM THE LOGICAL ASSIGNMENTS OF A SYSTEM. ASSIGNMENTS 
MAY BE ON A SYSTEM WIDE OR LOCAL (TERMINAL) BASIS. 


me Me Me MO MO Ne 


-ASECT 
-=0 
L.LNK: .BLKW 1 ;LINK TO NEXT LCB 
L.NAM: .BLKW 1 ; LOGICAL NAME OF DEVICE 
L.UNIT: .BLKB al ; LOGICAL UNIT NUMBER 
L.TYPE: .BLKB 1 ;TYPE OF ENTRY (O=SYSTEM WIDE) 
L.UCB: .BLKW 1 7;TI UCB ADDRESS 
L.ASG: .BLKW 1 ;ASSIGNMENT UCB ADDRESS 
L.LGTH=.-L.LNK ; LENGTH OF LCB 


- PSECT 
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000000 
000002 
000003 
000004 
000020 
000022 
000024 
000026 
000030 
000032 
000033 
000034 
000036 
000040 
000042 
000043 
000044 
000046 
000054 
000055 


000056 
000060 
000062 
000070 
000072 
000074 
000100 
000104 
000110 
000111 
000112 


000150 
000160 
000162 
000163 
000164 
000205 
000206 
000207 


me "0 Me MO NE =e We 


-=0 
V.TCNT: 
V.TYPE: 
V.VCHA: 
V.LABL: 
V.NXT: 
V.MVL: 
V.UVL: 
V.ATL: 
V.UCB: 
V.RVOL: 
V.MOU: 
V.TCHR: 
V.SEQN: 
V.SECN: 
V.TPOS: 
V.PSTA: 
V.TIMO: 
V.STAT: 
V.TRTB: 
V.EFTV: 


LABEL 


=e "=e OMe 


V.BLKL: 
V.RECL: 
V.FNAM: 
V.FTYP: 
V.FVER: 
V.CDAT: 
V.EDAT: 
V.BLKC: 
V.RTYP: 
V.FATT: 


me me Ne 


V.WIND: 
V.MST2: 
V.FABY: 


V.ANSN: 
V.BOFF: 
V.DENS: 
V.DRAT: 


MTADFS 


-ASECT 


- BLKW 
- BLKB 
- BLKB 
- BLKB 
.- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
. BLKW 
- BLKB 
- BLKB 
.- BLKW 
- BLKW 
- BLKB 
- BLKB 


DATA 5S 


- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKB 


NULL WINDOW 


- BLKW 
.- BLKW 
- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKB 


No 
e 


Oe ee ee ee ee ee 


ECTION 


WERENNNRPHEPWHH 


SECTION 


e 


~ 
e 
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ANSI MAGTAPE SPECIFIC DATA STRUCTURES 
VOLUME SET CONTROL BLOCK OFFSET DEFININTIONS (VSCB) 


VOLUME SET AND PROCESS CONTROL SECTION 


; TRANSACTION COUNT 

; VOLUME TYPE DESCRIPTOR 
; VOLUME CHARACTERISTICS 
;FILE SET ID (FIRST SIX BYTES) 

;PTR TO NEXT VSCB NODE 

;PTR TO MOUNTED VOL LIST 

;PTR TO UNMOUNTED VOL LIST 

;ATL ADDR OF ACCESSING TASK TCB IN RSX11M 
;ADDR OF CURRENT UCB OR PUD 

;CURRENT RELATIVE VOL # 

;MOUNT MODE BYTE 

;UINT CHAR. FOR ALL UNITS USED FOR VOL SET 
;CURRENT FILE SEQUENCE # 

;CURRENT FILE SECTION # 

;POSITION OF TAPE IN TM'S TO NXT HDR1 

; PROCESS STATUS BYTE 

;BLOCKED PROCESS TIMEOUT COUNTER 

;STATUS WORDS USED BY COMMAND EXECUTION MODS 
; TRANSLATION CONTROL BYTE 
;FOR MAG TO RETURN IE.EOF, 


EOT, EOV 


;BLOCK LENGTH 

;RECORD LENGTH 

;FILE NAME 

;FILE TYPE 

;FILE VERSION # 

;CREATION DATE 

;EXPRIATION DATE ; 
;BLOCK COUNT FOR FILE SECTION 
;RECORD TYPE 

;FILE ATTRIBUTES FOR CARRIAGE CONTROL 
;REMAINDER OF FILE ATTRIBUTES 


;NULL WINDOW 
;MAGTAPE STATUS BITS 

;FILE ACCESSIBILITY BYTE (HDR1) 
; SPARE 

s;ANSI 17 CHARACTER FILE NAME 
sBUFFER OFFSET 

;REQUESTED UNIT DENSITY 
;DEFAULT RECORD ATTRIBUTES 
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000210 V.DBLK: .BLKW 1. ;DEFAULT BLOCK SIZE 
000212 V.DREC: .BLKW l. ;DEFAULT RECORD SIZE 
000214 S.VSCB=. ;SIZE OF VSCB 

-PSECT 


i 
; DEFINE OFFSETS INTO NULL WINDOW SECTION 


° 
e 


-ASECT 
-=0 
000000 W.CTL: .- BLKW 1 ;CONTROL WORD IN WINDOW 
V.WINC=V.WIND+W.CTL ;CNTRL WORD IN NULL WINDOW 
;RELATIVE TO THE VSCB 
-PSECT 


MOUNTED VOLUME LIST OFFSET DEFININTIONS (MVL) 


™=e =e 6S 


eASECT 
000000 M.NXT: .BLKW J. ;PTR TO NXT MVL NODE (11M) 
000002 M.UIC: .BLKW l ; OWNER UIC FROM RVOL #1 
000004 M.CH: - BLKW 1 ;U.CH/U.VP (11D) 
000006 M.PROT: .~BLKW L ; PROTECTION U.AR IN 11D 
000010 M.RVOL: .BLKB a ;RELATIVE VOL # OF MOUNTED VOLUME 
000011 M.STAT: .BLKB 1 ; VOLUME STATUS 
000012 M.VIDP: .BLKW 1 ; VOLUME ID POINTER 
000014 M.UCB: .BLKW 1 ;ADDR OF ASSOC UCB OR PUD 
000016 S.MVL=. ;SIZE OF MVL NODE 


-PSECT 


UNMOUNTED VOLUME AND VOLUME LIST OFFSET DEFINITIONS (UVL) 


™e te Me 


-ASECT 

-=0 
000000 L.NXT: .BLKW 1 ;PTR TO NXT UVL NODE 
000002 L.VOL1: .BLKB 1 ;REL VOL # OF 1'ST VOL IN NODE 
000003 L.VOL2: .BLKB 1 ;REL VOL # OF 2'ND VOL IN NODE 
000004 L.VID1: .BLKB 6 ;VOL ID OF 1'ST VOL IN NODE 
000012 L.VID2: .BLKB 6 ;VOL ID OF 2'ND VOL IN NODE 
000020 S.UVL=. ;SIZE OF UVL NODE 


- PSECT 


7 SYSTEM DATA STRUCTURE CONTENT VALUES 


M.OLD = 200 ;OLD .FL300 VOLUME - VM.BYP WILL ALSO BE SET 
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VM.BYP 
VM. ULB 
VM.FSC 
VM .EXC 


2 ™e =e 


’ 
V2.INI 
V2.XH2 
V2.XH3 
V2.NH3 
V2.0AC 


° 
‘ 
e 
a 


‘ 
VP.RM 
VP.WM 
VP.UCM 
VP.SM 
VP.MOU 
VP.RWD 
VP.VFY 
VP. FOS 


RSX-11M-PLUS 


V.PSTA VALUES 


hou th wt Weal 


BLOCKED STATE = 


t 
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V.MST2 VALUES 


NF BN FE 


oo 
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;BYPASS LABEL PROCESSING 

; UNLABELED TAPE 

;OVERRIDE FILE SET ID CHECK 
;OVERRIDE EXPRIATION DATE CHECK 


;MAG WANTS US TO INITIALIZE NEXT OUTPUT 
;THIS FILE HAS NO HDR2, DON'T WRITE EOF2 
;THIS FILE HAS NO HDR3, DON'T WRITE EOF3 
;DON'T WRITE HDR3/EOX3 LABELS 

;OVERRIDE FILE/VOLUME ACCESSIBILITY 


- UNBLOCKED TRANSITION STATE 


;READ DATA MODE 
;WRITE DATA MODE 

; UNLABELLED CREATE POSITIONING MODE 
;SEARCH MODE 

sMOUNT MODE 

;REWIND OR VOL VERIFICATION WAIT 


;PROCESS IN POSITIONING MODE 
+ (MULTI-SECTION FILE) 


- (UNBLOCKED TRANSITION STATE VALUES) 


PROCESS TIMED OUT BIT 0 = 1 


VP.TO=1 


me 


; NULL WINDOW CONTROL BIT DEFINITIONS 


WI.RDV 
WI.WRV 
WI.EXT 
WI.LCK 


e ™e ee 


e 
MS.VER 
MS.RID 
MS.NMO 
MS.TMO 
MS.EXP 


Wout it ou 


MVL VALUES IN 


nou 


400 

1000 
2000 
4000 


200 


10 


;ACCESSED FOR READ 

; ACCESSED FOR WRITE 
; ACCESSED FOR EXTEND 
; LOCKED 


THE M.STAT FIELD 


;VOL ID NOT VERIFIED 

;VOL ID TO BE READ NOT CHECKED 
;MOUNT MESSAGE NOT GIVEN YET 
;ONE TIMEOUT ALREADY EXPRIED 
EXPIRATION DATE MESSAGE GIVEN 
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i 
; MISC BITS USED IN MOUNT (STORED IN V.STS) 


o 

MO.OVR = ue ;OVER RIDE VOL NAME SWITCH 
MO.JIC = Z ; EXPLICIT UIC GIVEN 

MO.PRO = 4 ;EXPLICIT PROTECTION GIVEN 
MO.160 = 10 ;1600 BPI SPECIFIED 


me “oe ™O tO MS 


=e se “OE 


=e "8 Me MO ME NO Me MO Me NO Me MO MO 


=e ™e Me 
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OLRDF$ S$SSGBL 


THIS MODULE DEFINES THE ONLI 


OLRDF$ 


NE RECONFIGURATION INTERFACE 


AS IMPLEMENTED BETWEEN THE RSX-11M-PLUS TASKS CON, HRC, AND 


THE RDDRV. 


DEFINE THE I/O FUNCTION CODE 


-MCALL .WORD.,DEFINS 


S FOR ONLINE RECONFIGURATION CONTROL. 


-IF IDN <SSSGBL>,<DEFS$G> 


- <GBL=1 

- IFF 
- -GBL=0 

- ENDC 


THE FOLLOWING MACRO DEFINES 
OPERATIONS PERFORMED BY THE 


THE SUB-FUNCTION CODES FOR EACH OF THE 
HRC TASK AND A PARAMETER DESCRIBING 


THE ARGUMENTS REQUIRED FOR EACH FUNCTION. IN A MACRO CALL THE 
FOLLOWING ARE THE LEGAL COMBINATIONS FOR THE ‘MASK' 


PARAMETER: 
<> SIGNI 
<D> SIGNI 


FYING NO PARAMETERS 
FYING ONE BUFFER DESCRIPTOR 


<D,D> SIGNIFYING TWO BUFFER DESCRIPTORS 

<D,CT> SIGNIFYING ONE DESCRIPTOR AND 'CT! BYTES OF 
PARAMETERS 

<CT> SIGNIFYING 'CT' BYTES OF PARAMETERS 


-MACRO FUNC NAME, SUBF,FUN,MASK 


e-WORD. I0.'NAME,SUBF, 
FUNCA NAME, <MASK> 
- ENDM 


e-MACRO FUNCA NAME,MSK 


PARC T=0 
DESCT=0 
-IRP X,<MSK> 


FUN 


-IIF IDN <X>,<P> PARCT=PARCT+1 
e-IIF IDN <X>,<D> DESCT=DESCT+1 
-IIF GT <PARCT-17> .ERROR INVALID PARAMETER COUNT 
-IIF GT <DESCT-17> .ERROR INVALID DESCRIPTOR COUNT 


- ENDR 


TEMP=<DESCT*4>+<PARCT* 
eWORD. IOS'NAME,<<DES 
- ENDM 


2> 
CT*20+PARCT>>, TEMP 


DEFINE ONLINE RECONFIGURATION I/0 FUNCTIONS 


eWORD. I0.MFC,000,001 
e-WORD. I0.RSC,000,002 
-WORD. I0.WSC,000,006 


; MULTI-FUNCTION MODIFY CONFIGURATN 
7; READ SYSTEM CONFIGURATION 
; MODIFY DEVICE CONFIGURATION 
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° 
7 


; DEFINE SUBFUNCTIONS TO MODIFY DEVICE CONFIGURATION 


. 
’ 


™e Se Ne SO Me 


FUNC ONL,001,006,<D,D> ; SET DEVICE ONLINE 
FUNC OFL,002,006,<D, D> SET DEVICE OFFLINE 

FUNC MAI, 003,006,<D,D> SET DEVICE IN MAINT MODE 
FUNC CAC,004,006,<> CACHE CONTROL 

FUNC MEM,005,006,<> MIND CONTROL 


bk ak ek i ek nt ek nk nd 


FUNC STN, 006,006,<P,P> RECONFIGURATION CONTROL, 
SPECIFY TASK NAME 

FUNC HRC ,007,006,<P,P> RECONFIGURATION CONTROL, 
HRC OPERATING MODE 

FUNC ONE,010,006,<P,P> ; ON <CONDITION> <COMMAND> 

FUNC STA,011,006,<D> ; RETURN DEVICE STATE 

FUNC IF ,012,006,<P,P> ; IF <CONDITION> <COMMAND> 

FUNC RLI,013,006,<D,D,D,D>  ; LINK UNIBUS RUN 

FUNC RUL,014,006,<D,D,D,D>  ; UNLINK UNIBUS RUN 

FUNC MBO,015,006,<P,P,D,D,D,D,D,D,D,D> ; MEM BOX ONLINE 

FUNC RSW,016,006,<D,D,D,D>  ; SWITCH BUS 

FUNC WAT,017,006,<D> ; WRITE ATTRIBUTES 

FUNC RAT,020,006,<D, D> ; READ ATTRIBUTES 

FUNC MBF,021,006,<P,P,D,D,D,D,D,D,D,D> ; MEM BOX OFFLINE 

IOSMAX=21 ; DEFINE MAXIMUM SUBFUNCTION 


STOP PROCESSING COND ENCOUNTERED 


DEFINS IS.HRG,6. ; 
7 SECOND STATUS WORD IS ARGUMENT 


DEFINE A MACRO, WHICH WHEN EXPANDED WITH THE APPROPRIATE 
DEFINITION FOR .IOER. WILL DEFINE THE PRIVATE ERROR CODES USED BY 


HRC AND CON. 


-MACRO OLREMS 


SSSVAL=-256. ; DEFINE INITIAL ERROR NUMBER VALUE 
- LOER. IESDAL,<DEVICE already linked> 

- IOER. IESDNL,<DEVICE not linked> 

~IOER. IESPRM,<Parameter error> 

-IOER. IESSYN,<Syntax error> 

-IOER. IESAFE,<Attribute format error> 

-IOER. IESTMU,<HRC... Internal tables insufficient for this system> 
-IOER. IESCAB,<Unable to access busrun> 

-IOER. IESTRP,<HRC... internal addressing error> 

-IOER. IESALG,<Memory box parameter error> 

-IOER. IESTQU,<Timeout on unit quieting operation> 

- IOER. IESEPO,<ONLINE CPU failure> 

- [OER. ITESEUO,<ONLINE UNIT failure> 

- IOER. IESECO,<ONLINE CONTROLLER failure> 

- TIOER. IESEPF,<OFFLINE CPU failure> 

- IOER. IESEUF,<OFFLINE UNIT failure> 

~ LOEBR. IESECF,<OFFLINE CONTROLLER failure> 

~-IOER. IESCFU,<Attempt to quiet unit for controller failed> 

-IOER. IESCSR,<CSR for controller not present in I/O page> 
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-IOER. IESSWF,<Unable to switch unit away from current controller> 
~IOER. IESICE,<HRC... detected I/0 database consistancy error> 

-IOER. IESSCE,<Executive or Driver status change error> 

-IOER. IESMDE,<HRC... Memory descriptor format error> 

~-IOER. IESNFW,<No path to target device is available> 

-IOER. IESCXT,<Unable to take unit with context offline.> 

~-IOER. IESIDU,<Invalid device descriptor> 

-IOER. IESUNK,<Device is unknown in this configuration> 

-IOER. IESSZE,<HRC... Unable to access device to size drive> 

-IOER. IESPOB,<HRC... Can't take box offline. Partition overmaps box> 
~-IOER. IESNLB,<HRC... Can't take box offline. Not last box in memory> 
~IOER. IESOMP,<HRC... Can't modify partition size. Overmap exists> 
-IOER. IESPOC,<HRC... Can't modify partition size. Occupied> 

-IOER. IESDFE,<HRC... Request format error.> 

-IOER. IESIDS,<HRC... Invalid device specification.> 

~IOER. IESUOE,<HRC... Unkown error from online/offline call> 

- ENDM 


CONDITION CODES FOR CONDITIONS TESTED BY IO.ONE AND IO.IF FUNCTS 


me te Ne 


COSONL = 1 ; IF DEVICE NOW ONLINE 
COSOFL = 2 ; IF DEVICE NOW OFFLINE 

COSUNK = 3 : UNKNOWN DEVICE 

COSACC = 4 ; ACCESSABLE (ACCESS PATH EXISTS) 
COSANY = 5 ; ANY ERROR CONDITION 

COSMAI = 6 ; MAINTENANCE MODE 

COSMAX = 6 > MAXIMUM CODE 


CONDITION COMMAND CODES FOR IO.ONE AND IO.IF FUNCTIONS 


me "Me Me 


CDSSTO = 2 ; 'STOP' COMMAND 

CDSGOT = 4 ; ‘GOTO' 

CDSCON = 6 ; ‘CONTINUE’ 

CDSMAX = 6 ; MAXIMUM CONDITION DEFINED 


ARGUMENT DEFINITION FOR IO.HRC FUNCTION 


=e =e TO 


MSLOG = 1 ; SUPRESS CONFIG TRANSMISSION TO ERRLOG 
MSINIT = 2 ; INITALIZE HRC 

MSDEBG = 4 ; SET HRC INTO DEBUG MODE (DEVELOPMENT ONLY) 
MSEXIT = 10 ; EXIT REQUEST (FROM ABORT AST REQUEST) 


DEFINE TABLE OFFSETS AND STATUS BITS RETURNED IN RESPONSE TO 
A 'READ CONFIGURATION! QIO 


mo Se Se Se 


-ASECT 
-=0 
000000 CSDTYP: .BLKB 1 ; ENTRY TYPE FIELD 
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000001 


000002 
000003 
000004 
000005 


000006 
000012 


000034 


000000 
000000 
000002 
000003 
000004 
000005 
000006 


000010 


ENTRY 


=e ee Me 


CSDECT: 


CSDVER: 
CSDSTD: 


CSDMUB: 
CSDMCT: 


CSDFAC: 
CSDIDN: 


CSSTD: 


me te Me 


-=0 

CSDTYP: 
CSDNAM: 
CSDPUN: 
CSDLUN: 
CSDSCT: 
CSDEVT: 
CSDSTS: 


me tO Me 


CSDST2: 


TYPE CODES ARE AS 


ETSHDR 
ETSEND 


a. 
2 


lt 


ETSDEV ‘A 


~ 


- BLKB 


- BLKB 
- BLKB 
- BLKB 
- BLKB 
- EVEN 
.- BLKW 2 

- BLKW 9. 


ee 


. BLKW 
.- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKW 


a 


FLAG VALUES FOR CSDSTS 


CSSATR=1 
CSSEXF=76 


CSSSUB=100 
;CSSXXX=200 
CSSOFL=400 
CSSPDF=1000 
CSS$POR=2000 
CSSMBD=4000 
CSSUNK=10000 
CSSACC=20000 
CSSMTD=40000 
CSSDRV=100000 


- BLKW 1 


CSSPUN=20 


CSSCRD=40 


=e se 


me Se Me Me Me NO =e 


me Me 


=e 


Te a ee ee eT) 


me Me MO Me MO MO Me NO Me MO Me MO NO 


=e 


me MO Me NO 


FOLLOWS 


CONFIGURATION HEADER ENTRY 
END OF CONFIGURATION DATA 


MIN VALUE FOR DEVICE SPECIFICATION ENTRY 


COUNT OF TABLE ENTRIES (CPUS+SWITCHED 

BUS RUNS+CONTROLLERS+4UNITS) 

VERSION OF RECONFIGURATION TASK PROTOCAL 
SIZE OF HEADER 

MAXIMUM UNIBUS RUNS SUPPORTED 

MAX CONTROLLERS OF A GIVEN TYPE SUPPORTED 


FACILITES SUPPORTED IN HOST SYSTEM 
HRC VERSION AND BUILD TIMESTAMP 


SIZE OF THE TABLE HEADER 


OFFSETS WITHIN THE FIXED PORTION OF A GIVEN ENTRY 


ENTRY TYPE CODE 

TWO ASCII CHARACTER UNIT OR CONTR NAME 
CONTROLLER NUMBER (0-255.) 

LOGICAL UNIT NUM IF THIS DEVICE IS A UNIT 
SUB-CONTROLLER NUMBER 

DEVICE TYPE CODE 

DEVICE STATUS MASK 


VARIABLE LENGTH ATTRIBUTE INFO IS APPENDED 
FIELD IN CSDSTS CONTAINING COUNT OF 
ADDITIONAL BYTES IN THIS DEVICE ENTRY 
THIS IS A SUB-CONTROLLER DEVICE 

UNUSED 

1=>DEVICE IS OFFLINE, O=>DEVICE IS ONLINE 
DEV IS RESTRICTED TO PRIVILEGED DIAG FNS 
THIS IS A MULTIPORT DEVICE 

DEVICE IS A MASS BUS DEVICE 

DEVICE IS UNKNOWN 

AN ONLINE ACCESS PATH EXISTS TO THIS DEV 
DEV IS MOUNTED(DISK) OR LOGGED IN (TERM) 
A DRIVER IS LOADED FOR THIS DEVICE 


STATUS EXTENSION 


l=> THIS DEVICE SPECIFIED WITH PHYSICAL 
UNIT NUMBER 

l=> THIS IS A CONTROLLER RELATIVE DEVICE 
SPEC 
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000012 


000016 


000016 


000020 


000016 


000020 


000022 


000016 


000020 


me te MS 


CSDDAT: 


CSSME: 


me te te 


e me 6 Me 


=CSSME 
CSDKPO: 


CSSCT: 


CS$PRC=100 


CSS$CTL=200 


CSSDCL=3 400 


DEVICE CLASS 


DCSUNI 
DCSCTL 
DCSMKU 
DC SMKC 
DCSSBU 
DCSSBC 
DC SC PU 
;DCSXXX 


- BLKW 


- BLKW 


VALUES 


NUS W NFO 


2 


FOR CONTROLLERS 


1 


VARIABLE PORTION OF A 


; 
; FOR UNIT ENTRIES 
; 


=CSSME 
CS$DCTN: 


CSDUPO: 


CSSUN: 


- BLKW 


- BLKW 


1 


1 


1 


me ™e ~™O Me NO 


me Me MO Me MS NO MO NO 


~e 


=e 


OLRDF$ (Cont.) 


l=> THIS IS A PORT RELATIVE CONTROLLER 
SPEC 

DEVICE IS A CONTROLLER (MUST BE SIGN BIT) 

DEVICE CLASS CODE FIELD. MUST BE LOW ORDER 

BITS OF HIGH BYTE. 


UNIT 

CONTROLLER 

MEMORY BOX UNIT 

MEMORY BOX CONTROLLER 
SWITCHED BUS UNIT 
SWITCHED BUS CONTROLLER 
CPU 

UNUSED 


DEVICE DEPENDANT DATA 


SIZE IF A MINIMUM ENTRY 


GIVEN ENTRY 


me me Ne MO 


me me TO =e se MO 


me 


=e Me Ge 


PORT-STATUS-WORD. THIS DESCRIBES THE BUS 
RUN, CPU OR SWITCHED BUS, TO WHICH THIS 
CONTROLLER IS CONNECTED. 

MIMIMUM SIZE OF A CONTROLLER ENTRY 


CONTROLLER NAME. TWO CHARACTER ASCII CODE 
OF THE CONTROLLER TO WHICH THIS UNIT IS 
ATTACHED. 

PORT-STATUS-WORD. THIS IS THE 

FIRST OF THE PSWS DESCRIBING THE CONTR(S) 
TO WHICH THIS UNIT IS CONNECTED. 

MIMIMUM SIZE OF A UNIT ENTRY 


PORT-STATUS-WORD. THIS IS THE BUS 
NUMBER FOR THIS CPU. 
MINIMUM SIZE OF A CPU ENTRY 
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000016 
000020 


000030 


000000 
000002 
000003 
000004 
000006 


. 
, 


; FOR MEMORY BOXES 


-=CSSME 
CSDCTN: .BLKW 1 ; CONTROLLER NAME. 

- BLKW 4 ; MAXIMUM OF 4 PORTS FOR MEMORY CONTROLLERS 
CSSMB: 7 MAXIMUM SIZE OF A MEMORY BOX ENTRY 


S'PATUS BIT DEFINITIONS FOR THE PORT STATUS WORD 


l=> PORT IS OFFLINE 

UNUSED 

THIS PORT IS THE CURRENT PORT (S.KRB 
REFERENCES THIS PORT 


CPSOFL=400 
CPSXXX=1000 
CPSCUR=2000 


=e se te SO Me BO 


CPSXXX=4000 UNUSED 

CPS$XXX=10000 UNUSED 

CPSACC=20000 ; THIS PORT HAS AN ACCESS PATH 
CPSMTD=40000 ; PORT HAS CONTEXT OR SERVICES A DEVICE 


; HAVING CONTEXT 
CPSXXX=100000 ; UNUSED 


; DEVICE ATTRIBUTES CODES 


-MACRO ATT NAME, SIZ 


SSSTMP=SSSTMP+1 
DEFINS DAS'NAME,SSSTMP!<400*SIZ> 


. ENDM 
SSSTMP=0 

ATT CSR,2 ; CSR ADDRESS 

ATT VEC,2 ; VECTOR ADDRESS 

ATT UBR, 2 ; UNIBUS RUN 

ATT TYP,2 ; DEVICE TYPE, READ ONLY 

ATT VOL,12. ; MOUNTED VOLUME NAME, READ ONLY 
ATT ERR,10 ; DEVICE ERROR COUNTERS, READ/WRITE 
ATT PRI, 2 ; DEVICE INTERRUPT PRIORITY 

ATT MBP,6 ; MEMORY BOX PARAMETER 

ATT STE,2 ; SANITY TIMER ENABLE/DISABLE 

ATT SAL, 2 ; ALARM ENABLE/DISABLE 

ATT DSN, 2 ; DEVICE SERIAL NUMBER 

ATT CSN,10 ; CPU SERIAL NUMBERS 


MEMORY BOX ATTRIBUTE BUFFER 


me Me Ne 


-ASECT 
-=0 
CSMBAS: .BLKW 
CSMINT: .BLKB 
- BLKB 
CSMSIZ: .BLKW 
CSMGRN: .BLKW 


BASE ADDRESS OF BOX 

INTERLEAVE FACTOR 

FREE BYTE 

SIZE OF BOX IN 32 WORD BLOCKS 
BOX GRANULARITY. "BYTES-PER-UNIT" 


bt Re pe 
~ =e =e Se -” 


000010 
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CSMDSC: ; SIZE OF BOX ATTRIBUTE BUFFER 


- PSECT 


MACRO FOR THE DEFINITION OF DEVICE TYPE CODES 


=e 6s tO 


-MACRO DEVCDS S$SSGBL 
-MCALL DEFINS 


-IF IDN <$$S$GBL>,<DEFSG> 
..-GBL=1 

.IFF 
...GBL=0 

. ENDC 


-MACRO DEV X 
DEFINS DS'X,SSSTMP 
SSSTMP=SSSTMP+1 


.ENDM 
SSSTMP = 0 

DEV UDET ; UNDETERMINED DEVICE TYPE 
DEV UKNO ; UNKNOWN DEVICE TYPE 

DEV RKO3 ; RKO3 

DEV RKO5 ; RKOS5 

DEV RK5F ; RKO5-F (DUAL DENSITY FIXED CARTRIDGE) 
DEV RX01 ; RXOl 

DEV RX02 ; RX02 (DUAL DENSITY RXO1) 
DEV RLO1 : RLOL 

DEV RLO2 ; RLO2 

DEV RPO2 ; RPO2 

DEV RPO3 ; RPO3 

DEV RPO4 ; RPO4 

DEV RPO5 ; RPOS 

DEV RP06 ; RPOG 

DEV RPO7 ; RPO7 

DEV RK06 ; RKO6 

DEV RKO7 ; RKO7 

DEV RMO2 ; RMO2 

DEV RMO3 ; RMO3 

DEV RMO5 ; RMOS 

DEV RM80 ; RM80 

DEV RSO3 ; RSO3 

DEV RSO04 ; RSO4 (DUAL DENSITY RSO3) 
DEV RF11 ; RF11/RS08 
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DEV TU1O ; TU1O 

DEV TU16 : TU16 

DEV TU45 > TU4S 

DEV TU77 : TU77 

DEV TU78 ; TU78 

DEV TSll ; TSll 

DEV TMO2 ; TMO2 

DEV TMO3 ; TMO3 

DEV TM78 : TM78 

DEV TU56 ; TU56 

DEV TU58 ; TU58 

DEV TU60 ; TU60 

DEV MSCP ; UDA5O 

DEV RA60 ; RAG6O 

DEV RA80 ; RA80 

DEV RA81 ; RA81 

DEV ML11 > ML11 

DEV TERM ; TERMINAL 
SSSTMP=370 

DEV USRO ; USER TYPE 0 
DEV USR1 + USER TYPE 1] 
DEV USR2 : USER TYPE 2 
DEV USR3 ; USER TYPE 3 
DEV USR4 + USER TYPE 4 
DEV USR5 ; USER TYPE 5 
DEV USR6 ; USER TYPE 6 
DEV USR7 ; USER TYPE 7 


A-46 


000000 
000002 
000004 
000010 
000012 
000014 
000016 
000016 
000020 
000024 
000030 
000032 
000034 
000042 
000043 


000044 


000000 
000002 
000003 
000004 
000010 
000012 
000014 
000016 
000016 
000020 
000022 
000024 
000026 
000030 
000032 
000034 
000036 
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PCBDFS$ 


PCBDF$ 


1p OYSDEF 


MAIN PARTITION PCB 


.ASECT 
-=0 
P.LNK: .BLKW 1 ;LINK TO NEXT MAIN PARTITION PCB 
.BLKW 1 ; (UNUSED) 
P.NAM: .BLKW 2 ;PARTITION NAME IN RADSO 
P.SUB: .BLKW 1 ;POINTER TO FIRST SUBPARTITION 
P.MAIN: .BLKW 1 ;POINTER TO SELF 
P.REL: .BLKW 1 ;STARTING PHYSICAL ADDRESS IN 32W BLOCKS 
P.BLKS: 
P.SIZE: .BLKW 1 ;SIZE OF PARTITION IN 32W BLOCKS 
P.WAIT: .BLKW 2 ;PARTITION WAIT QUEUE LISTHEAD 
-BLKW 2 ; (UNUSED) 
P.STAT: .BLKW 1 ;PARTITION STATUS FLAGS 
P.ST2: .BLKW 1 ;STATUS EXTENSION FOR COMMON AND MAIN PCB'S 
.BLKW 3 ; (UNUSED) 
P.HDLN: .BLKB 1 ;SIZE OF EXTERNAL HEADER IN 32W BLOCKS 
P.IOC: .BLKB 1 ;PARTITION I/O COUNT 
$S$=. 
P.RRM: .BLKW 1 ;REQUIRED RUN MASK 
.IF NDF MS$SPRO 
-=SSS 
. ENDC 
.IF NB SYSDEF 
P.LGTH=. ;PARTITION CONTROL BLOCK LENGTH 
. ENDC 
P 
; TASK REGION PCB 
-=0 
P.LNK: .BLKW 1 ;UTILITY LINK WORD 
P.PRI: .BLKB 1 ;PRIORITY OF PARTITION 
P.RMCT: .BLKB 1 ;RESIDENT MAPPED TASKS COUNT 
P.NAM: .BLKW 2 ;PARTITION NAME IN RAD50 
P.SUB: .BLKW 1 ;POINTER TO NEXT SUBPARTITION 
P.MAIN: .BLKW 1 ;POINTER TO MAIN PARTITION 
P.REL: .BLKW 1 ;STARTING PHYSICAL ADDRESS IN 32W BLOCKS 
P.BLKS: 
P.SIZE: .BLKW 1 ;SIZE OF PARTITION IN 32W BLOCKS 
-BLKW 1 ; (UNUSED) 
P.SWSZ: .BLKW 1 ;PARTITION SWAP SIZE 
P.DPCB: .BLKW 1 ;CHECKPOINT ALLOCATION PCB 
P.TCB: .BLKW 1 ;TCB ADDRESS OF OWNER TASK 
P.STAT: .BLKW 1 ;PARTITION STATUS FLAGS 
P.HDR: .BLKW 1 ;POINTER TO HEADER CONTROL BLOCK 
-BLKW 1 ; (UNUSED) 
P.ATT: .BLKW 2 ;ATTACHMENT DESCRIPTOR LISTHEAD 
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000042 
000043 


000000 
000002 
000003 
000004 
000010 
000012 
000014 
000016 
000016 
000020 
000022 
000024 
000026 
000030 
000032 
000034 
000036 
000042 
000043 


P.HDLN: .BLKB 
P.IOC: - BLKB 
$S$S=. 
P.RRM: - BLKW 
~IF NDF 
-=SSS 
- ENDC 


e =e se Me 


~I1F NDF MSSPRO 


=0 
P.LNK: - BLKW 
P.PRI: - BLKB 
P.RMCT: .BLKB 
P.NAM: .BLKW 
P.SUB: .BLKW 
P.MAIN: .~BLKW 
P.REL: - BLKW 
P.BLKS: 
P.SIZE: ~BLKW 
P.CBDL: .BLKW 
P.SWSZ: .BLKW 
P.DPCB: .~BLKW 
P.OWN: - BLKW 
P.STAT: .~BLKW 
Peol2: - BLKW 
P.PRO: .BLKW 
P.ATT: .BLKW 
P.HDLN: .BLKB 
P.10C: .BLKB 
S$$=. 
P.RRM: .BLKW 
-=SS$ 

- ENDC 

-PSECT 


. 
f 


; PARTITION STATUS WORD 


PS .OUT=100000 
PS.CKP=40000 
PS.CKR=20000 
PS.CHK=10000 
PS.FXD=4000 
PS .CAF=2000 
PS.LIO=1000 
PS.NSF=400 
PS .COM=200 
PS.LFR=100 
PS. PER=40 


COMMON REGION 


— 


1 


MSS$SPRO 


PCB 


et Oe ee 


Le Oe le 


i 


;SIZE OF EXTERNAL HEADER IN 32W BLOCKS 


; PARTITION 


I/O COUNT 


;REQUIRED RUN MASK 


;UTILITY LINK WORD 


PRIORITY OF PARTITION 
;RESIDENT MAPPED TASKS COUNT 


; PARTITION 


NAME IN RAD50 


;POINTER TO NEXT SUBPARTITION 
;POINTER TO MAIN PARTITION 
;STARTING PHYSICAL ADDRESS IN 32W BLOCKS 


;SIZE OF PARTITION IN 32W BLOCKS 
7COMMON BLOCK DIRECTORY LINK 


; PARTITION 


SWAP SIZeE 


;POINTER TO DISK PCB 
;OWNING UIC OF REGION 


; PARTITION 


STATUS FLAGS 


STATUS EXTENSION FOR COMMON AND MAIN PCB!IS 
; PROTECTION WORD [DEWR,DEWR, DEWR, DEWR] 
;ATTACHMENT DESCRIPTOR LISTHEAD 

;SIZE OF EXTERNAL HEADER IN 32W BLOCKS 


; PARTITION 


I/O COUNT 


;REQUIRED RUN MASK 


BIT DEFINITIONS 


; PARTITION 
; PARTITION 
; PARTITION 
; PARTITION 
; PARTITION 


;CHECKPOINT SPACE ALLOCATION FAILURE (1=YES) 


;MARKED BY 
; PARTITION 


IS OUT OF MEMORY (1=YES) 
CHECKPOINT IN PROGRESS (1=YES) 
CHECKPOINT IS REQUESTED (1=YES) 
IS NOT CHECKPOINTABLE (1=YES) 
IS FIXED (1=YES) 


SHUFFLER FOR LONG I/O (1=YES) 
IS NOT SHUFFLEABLE (1=YES) 


; LIBRARY OR COMMON BLOCK (1=YES) 
;LAST LOAD OF REGION FAILED (1=YES) 


;PARTIY ERROR OCCURED IN THIS REGION (1=YES) 
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000000 
000002 
000004 
000006 
000010 
000012 
000014 
000016 
000020 


PS.DEL=10 


PS.AST=4 


hy TY we we we 
Dw 


- UBT=100000 
UBS=40000 


PR.UBR=20000 
PR.UBP=10000 
PR.UBN=4000 
PR. UBM=2000 
PR.UBL=1000 
PR.UBK=400 


PR.UBJ=2 
PR.UBH=1 


00 
00 


PR.UBF=40 


PR.UBE=2 


0 


PR.CPD=10 


PR.CPC=4 
PR.CPB=2 
PR.CPA=1 


° 
’ 
° 
e 
° 
a 
° 
’ 
Pp 


P2.CPC=2 


2. LMA=40000 


0000 


P2.SEC=4000 


P2.PAR=2 


000 


P2.POL=1000 
P2.CPU=400 
P2.PIC=200 


P2.RON=1 


00 


P2.DRV=40 


P2.APR=7 


me me we 


-=0 

P.LNK: 
P.UCB: 
P.LBN: 


P.SUB: 
P.MAIN: 
P.REL: 
P.SIZE: 
P.DLGH=. 


-ASECT 


- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 


REQUIRED RUN MASK 


STATUS EXTENSION WORD 
(THESE BITS CAN 


CHECKPOINT FILE PCB 


Pe REP He EE 


PCBDF$ (Cont.) 


;PARTITION SHOULD BE DELETED WHEN NOT 
;ATTACHED (1=YES) 
; PARTITION HAS REGION LOAD AST PENDING 


;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;PROCESSOR D 
sPROCESSOR C 
; PROCESSOR B 
;PROCESSOR A 


mymanrs 2Z90DMVN + 


BIT DEFINITIONS 
ONLY BE EXAMINED IN COMMON OR MAIN PCB!S) 


;DON'T SHUFFLE,DELETE SPINDLE OR MUTILATE 
;THIS PARTITION 

;CPCR INITIATED CHECKPOINT PENDING 

;THIS IS RO SECTION OF MU TASK 

;WITH TCB IN SEC. POOL 

:THE FIXER TASK HAS HANDLED A PARITY ERROR 
;SECONDARY POOL PARTITION 

s;MULTIPROCESSOR CPU PARTITION 

;POSITION INDEPENDENT LIBRARY OR COMMON 

; (1=YES) 

;READ-ONLY COMMON (1=YES) 

;DRIVER COMMON PARTITION (1=YES) 

;STARTING APR NUMBER MASK FOR NON-PIC COMMON 


; LINK WORD OF CHECKPOINT FILE PCB'S 

;UCB ADDRESS OF CHECKPOINT FILE DEVICE 
;HIGH PART OF STARTING LBN 

;LOW PART OF STARTING LBN 

;POINTER TO FIRST CHECKPOINT ALLOCATION PCB 
;MUST BE O (FOR SRLPR1) 

;CONTAINS O IF FILE IN USE, 1 IF NOT IN USE 
;SIZE OF CHECKPOINT FILE IN 256W BLOCKS 
;LENGTH OF ALL DISK PCB'S 
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PCBDF$ (Cont.) 


000000 
000010 
000012 
000014 
000016 


000000 
000002 
000004 
000006 
000010 
000012 
000014 
000016 


000000 
000002 
000003 
000004 
000006 
000010 
000011 
000012 
000014 


e =e ™e TS 


=0 


P.SUB: 
P.MAIN: 
P.REL: 
P.SIZE: 


e =e =e TO 


=0 
P.FIDI1: 
P.UCB: 
P.LBN: 


P.FID2: 
P.MAIN: 
P.REL: 

P.FID3: 


=e =O 6M 


-=0 
A.PCBL: 
A.PRI: 
A.IO0C: 
A.TCB: 
A.TCBL: 
A.STAT: 
A.MPCT: 
A.PCB: 


A.LGTH=. 


me te Ne 


.- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 


COMMON TASK 


. BLKW 
- BLKW 
- BLKW 
- BLKW 
. BLKW 
- BLKW 
- BLKW 
- BLKW 


-ASECT 


'. BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKW 


- PSECT 


AS. PRO=100 
AS.SBP=20 
AS. RBP=40 
AS.DEL=10 


AS.EXT=4 
AS. .WRT=2 
AS.RED=1 


CHECKPOINT ALLOCATION 


ee en NS 


PCB 


; (UNUSED) 
;LINK TO NEXT CHECKPOINT ALLOCATION PCB 
s;ADDRESS OF CHECKPOINT FILE PCB 

;RELATIVE POSITION IN FILE IN 256W BLOCKS 
;SIZE ALLOCATED IN 256W BLOCKS 


IMAGE FILE PCB 


Se ee ee oe 


ATTACHMENT DESCRIPTOR 


hh pe pe 


ATTACHMENT DESCRIPTOR 


;FILE ID WORD FOR SAVE ; 

;UCB ADDR OF DEVICE ON WHICH COMMON RESIDES 
;HIGH PART OF STARTING LBN 

;LOW PART OF STARTING LBN 

;FILE ID WORD FOR SAVE 

; POINTER TO SELF 

;ALWAYS CONTAINS A 0 

;FILE ID WORD FOR SAVE 


OFFSETS 


;PCB ATTACHMENT QUEUE THREAD WORD 

;PRIORITY OF ATTACHED TASK 

71/0 COUNT THROUGH THIS DESCRIPTOR 

;TCB ADDRESS OF ATTACHED TASK 

;TCB ATTACHMENT QUEUE THREAD WORD 

;STATUS BYTE 

s;MAPPING COUNT OF TASK THRU THIS DESCRIPTOR 
;PCB ADDRESS OF ATTACHED TASK 

;LENGTH OF ATTACHMENT DESCRIPTOR 


STATUS BYTE BIT DEFINITIONS 


;A.TCB IS SEC POOL TCB BIAS (1=YES) 
;CACHE BYPASS REQUESTED 

;REQUEST TO NOT BYPASS CACHE 

;TASK HAS DELETE ACCESS (1=YES) 
;TASK HAS EXTEND ACCESS (1=YES) 
TASK HAS WRITE ACCESS (1=YES) 
;TASK HAS READ ACCESS (1=YES) 


177774 
177776 
000000 
000002 


000004 
000006 
000010 
000012 
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PKTDFS 


PKTDFS 


ASYNCHRONOUS SYSTEM TRAP CONTROL BLOCK OFFSET DEFINITIONS 


SOME POSITIONAL DEPENDENCIES BETWEEN THE OCB AND THE AST CONTROL 
BLOCK ARE RELIED UPON IN THE ROUTINE SFINXT IN THE MODULE SYSXT. 


~e te Me MO Te Te 


~ASECT 
-=177774 
A.KSR5: .BLKW 
A.DOSR: .BLKW 

. BLKW 
A.CBL: .BLKW 


;SUBROUTINE KISAR5 BIAS (A.CBL=0) 

;DEQUEUE SUBROUTINE ADDRESS (A.CBL=0) 

;AST QUEUE THREAD WORD 

;LENGTH OF CONTROL BLOCK IN BYTES 

;IF A.CBL = 0, THE AST CONTROL BLOCK IS 

;TO BE DEALLOCATED BY THE DEQUEUE SUBROUTINE 
;POINTED TO BY A.DQSR MAPPED VIA APR 5 
;VALUE A.KSR5. THIS IS CURRENTLY USED ONLY 
;BY THE FULL DUPLEX TERMINAL DRIVER FOR 
;UNSOLICITED CHARACTER ASTS. 

;IF THE LOW BYTE OF A.CBL = 0, AND THE 
HIGH BYTE IS NOT = 0, THE AST CONTROL BLOCK 
7IS A SPECIFIED AST, WITH LENGTH, C.LGTH. 
;IF THE HIGH BYTE OF A.CBL=0 

;AND THE LOW BYTE > 0, THEN 

;THE LOW BYTE IS THE LENGTH OF THE 

;AST CONTROL BLOCK. 

7;IF HIGH BYTE = 0 AND LOW BYTE IS NEGATIVE, 
;THEN THE BLOCK IS A KERNEL AST 

;BIT 6 IS SET IF S$SGFIN SHOULD 

s;NOT BE CALLED PRIOR TO DISPATCHING 

;THE AST, AND THE LOW SIX BITS (5-0) 
;REPRESENT THE INDEX/2 INTO THE 

;KERNEL AST DISPATCH TABLE (SKATBL) 

;NUMBER OF BYTES TO ALLOCATE ON TASK STACK 
;AST TRAP ADDRESS 

;NUMBER OF AST PARAMETERS 

;FIRST AST PARAMETER 


ee 


A.BYT: .BLKW 
A.AST: .BLKW 
A.NPR: .BLKW 
A.PRM: .BLKW 


en 


AS. FPA=1 ;CODE FOR FLOATING POINT AST 
AS.RCA=2 ;CODE FOR RECEIVE DATA AST 

AS. RRA=3 ;CODE FOR RECEIVE BY REFERENCE AST 
AS. PEA=4 ;CODE FOR PARITY ERROR AST 
AS.REA=5 ;CODE FOR REQUESTED EXIT AST 

AS. PFA=6 ;CODE FOR POWER FAIL AST 

AS. CAA=7 ;CODE FOR CLI COMMAND ARRIVAL AST 


ABORTER SUBCODES FOR ABORT AST (AS.REA) TO BE RETURNED ON USER'S 
STACK 


eo ~e te Me 


s 
AB.NPV=1 ;ABORTER IS NONPRIVILEGED (1=YES) 
AB. TYP=2 ABORT FROM DIRECTIVE (0=YES) 
ABORT FROM CLI COMMAND (1=YES) 
A. PLGH=70 ;SIZE OF PARITY ERROR AST CONTROL BLOCK 
A.DUCB=10 ;UCB OF TERM ISSUING DEBUG COMMAND 


A.DLGH=10. LENGTH OF DEBUG (AK.TBT) AST BLOCK 
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PKTDF$ (Cont.) 


000000 
000002 
000003 
000004 
000006 


000012 


KERNEL AST CONTROL CODES (A.CBL) 


AK. BUF=200 


AK. OCB=201 
AK.GBI=202 
AK. TBT=203 
AK. DIO0O=204 
AK.GGF=205 


;BUFFERED I/O COMPLETION 

THIS CODE MUST BE 200 UNTIL ALL 
*;REFERENCES IN TTDRV ARE FIXED 
;OFFSPRING TASK EXIT 

SEGMENTED BUFFERED I/O COMPLETION 
;TASK FORCE T-BIT TRAP (DEBUG CMD) 
;DELAYED I/O COMPLETION 

;GRP. GBL. RUNDWN 


; BIT DEFINITIONS FOR THE GET/SET INFORMATION DIRECTIVE. 


SF. PRV=100000 
SF.IN= 40000 


0 
- LNK: .- BLKW 


1 
G.GRP: .BLKB 1 
G.STAT: .~BLKB a 
G.CNT: .BLKW 1 
G.EFLG: .BLKW 2 
G.LGTH=. 
GS.DEL=1 


=e Se we 


MONITOR 


PC.HIH=1 
PC. LOW=2 
PC.ALF=4 
PC.XIT=200 


PC.NRM=PC.HIH*400 
PC.ALM=PC. LOW* 400 


e 
a 
e 
a 


PF.INS=40 
PF. LOG=100 
PF. REQ=200 
PF. ALL=177777 


;FUNCTION IS PRIVILEGED 
;FUNCTION IS AN INPUT FUNCTION 


GROUP GLOBAL EVENT FLAG BLOCK OFFSETS 


; LINK WORD 
;GROUP NUMBER 
;STATUS BYTE 
;ACCESS COUNT 
; EVENT FLAGS 


LENGTH OF GROUP GLOBAL EVENT FLAG BLOCK 


7;STATUS BIT -- MARKED FOR DELETE 


EXECUTIVE POOL MONITOR CONTROL FLAGS 


SPOLST IS THE SYNCHRONIZATION WORD BETWEEN THE EXEC AND POOL 


HIGH POOL LIMIT CROSSED (1=YES) 

;LOW POOL LIMIT CROSSED (1=YES) 

;POOL ALLOCATION FAILURE (1=YES) 
;FORCE POOL MONITOR TASK TO EXIT (MUST 
*7BE COUPLED WITH SETTING FE.MXT IN THE 
7;FEATURE MASK) 

;POOL TASK INHIBIT BIT FOR HIGH POOL 
;POOL TASK INHIBIT BIT FOR LOW POOL 


SPOLFL IS THE POOL USAGE CONTROL WORD 


;REJECT NONPRIVILEGED INS/RUN/REM 
;NONPRIVILEGED LOGINS ARE DISABLED 
;STALL REQUEST OF NONPRIV. TASKS 

;TAKE ALL POSSIBLE ACTIONS TO SAVE POOL 


A-52 
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OFFSPRING CONTROL BLOCK DEFINITIONS 


; SOME POSITIONAL DEPENDENCIES ARE DEPENDED ON BETWEEN THE OCB AND 
; THE AST BLOCK IN THE ROUTINE S$FINXT IN THE MODULE SYSXT. 
; 
0 


=0 
000000 -LNK: .BLKW al ;0CB LINK WORD 
000002 O.MCRL: .~BLKW Ai ;ADDRESS OF MCR COMMAND LINE 
000004 O.PTCB: .~BLKW A ; PARENT TCB ADDRESS 
000006 O.AST: .BLKW 1 ;EXIT AST ADDRESS 
000010 O.EFN: .BLKW 1 ;EXIT EVENT FLAG 
000012 O.ESB: .BLKW i ;EXIT STATUS BLOCK VIRTUAL ADDRESS 
000014 O.STAT: .BLKW 8. ;EXIT STATUS BUFFER 
000034 O.LGTH=. ;LENGTH OF OCB 


I/O PACKET OFFSET DEFINITIONS 


me te fe 


-ASECT 
-=0 


000000 I.LNK: . BLKW ti 71/0 QUEUE THREAD WORD 

000002 I.PRI: .BLKB 1 ;REQUEST PRIORITY 

000003 I.EFN: .BLKB 1 ; EVENT FLAG NUMBER 

000004 I.TCB: .BLKW i ;TCB ADDRESS OF REQUESTOR 

000006 I.LN2: .BLKW 1 ; POINTER TO SECOND LUN WORD 

000010 I.UCB: .BLKW 1 ;POINTER TO UNIT CONTROL BLOCK 

000012 I.FCN: .BLKW i 71/0 FUNCTION CODE 

000014 I.IOSB: .BLKW a ;VIRTUAL ADDRESS OF I/0 STATUS BLOCK 

000016 - BLKW 1 ;I/O0 STATUS BLOCK RELOCATON BIAS 

000020 - BLKW 1 31/0 STATUS BLOCK ADDRESS 

000022 I.AST: .BLKW i ;AST SERVICE ROUTINE ADDRESS 

000024 I.PRM: .BLKW 1 ;RESERVED FOR MAPPING PARAMETER #1 

000026 - BLKW 6 ;PARAMETERS 1 TO 6 

000042 - BLKW a ;USER MODE DIAGNOSTIC PARAMETER WORD 

000044 I.ATTL=. ;MINIMUM LENGTH OF I/O PACKET (USED BY 
;FILE SYSTEM TO CALCULATE MAXIMUM 
;NUMBER OF ATTRIBUTES) 

000044 I.AADA: .BLKW 2 ;STORAGE FOR ATT DESCR PTRS WITH I/0 

000050 I.LGTH=. ;LENGTH OF I/O REQUEST CONTROL BLOCK 

I.ATRL=6*8. ;LENGTH OF FILE SYSTEM ATTRIBUTE BLOCK 


;ADDRESS OF CLI'S TCB 
;CLI NAME 
;STATUS MASK 


000000 C.PTCB: .BLKW 
000002 C.PNAM: .BLKW 
000006 C.PSTS: .~BLKW 
000010 C.PDPL: .BLKB ;LENGTH OF DEFAULT PROMPT 
000011 C.PCPL: .BLKB ; LENGTH O CNTRL/C PROMPT 
000012 C.PRMT: ;START OF PROMPT STRINGS. DEFAULT 

7IS CONCATENATED WITH CONTROL C PROMPT 


a 


PKTDF$ (Cont.) 


000000 
000002 
000004 
000006 
000010 
000012 
000012 
000014 
000015 
000016 
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; 
; STATUS BIT DEFINITIONS 


CP.DSB=10 
CP. PRV=20 
CP.SGL=40 


CP.NIO=100 
CP.RST=200 


CP. EXT=400 
CP. POL=1000 


C.CLK: - BLKW 
C.CTCB: .BLKW 
C.CUCB: .~BLKW 
C.CCT: .BLKW 
C.CSTS: .~BLKW 


C.CMCD: 


C.CSO: - BLKW 
C.CTR: .BLKB 
C.CBLK: .BLKB 


CoCTXE: 
; 


CC.MCR=1 
CC. PRM=2 
CC. EXT=4 


CC. KIL=10 
CC.CLI=20 
CC.MSG=40 
CC. TTD=100 


eo 36 Me te Me MO 


‘ 

CM. INE=1 
CM. IND=2 
CM. CEN=3 
CM.CDS=4 
CM. ELM=5 
CM. EXT=6 
CM. LKT=7 
CM. RMT=8. 


CM.MSG=9., 


CODES: 0=127. 
CODES 128.-255. 


bt be pe 


;PASS EMPTY COMMANDS TO CLI 

;CLI DESIRES SYSTEM MESSAGES 

7;CLI WANTS COMMANDS FROM LOGGED OFF TTYS 
;CLI IS DISABLED 

;USER MUST BE PRIV TO SET TTY TO THIS CLI 
;DON'T HANDLE CONTINUATIONS (M-PLUS ONLY) 
;MCR..., HEL, BYE DO NO I/O TO TTY 

HEL, BYE DO NOT SET CLI ETC. 

;ABILITY TO SET TO THIS CLI IS RESTRICTED 
;TO THE CLI ITSELF 

;PASS TASK EXIT PROMPT REQUESTS TO CLI 
;CLI TCB IS IN SECONDARY POOL 


; LINK WORD 

;TCB ADDRESS OF TASK TO RECEIVE COMMAND 
;UCB ADDRESS OF RESPONSIBLE TERMINAL 
;CHARACTER COUNT, EXCLUDING TRAILING CR 
;STATUS MASK 

;SYSTEM MESSAGE CODE 

STARTING OFFSET OF VALID COMMAND TEXT 

; TERMINATOR CHARACTER 

;SIZE OF PACKET IN SEC POOL (32 WD.) BLOCKS 
;COMMAND TEXT, FOLLOWED BY CR 


STATUS BITS FOR COMMAND BLOCKS 


;FORCE COMMAND TO MCR 

; ISSUE DEFAULT PROMPT 

;TASK EXIT PROMPT REQUEST 

;DELETE ALL CONTINUATION PIECES FROM THIS TT 
;COMMAND TO BE RETREIVED BY GCCIS ONLY 

; PACKET CONTAINS SYSTEM MESSAGE TO CLI 
;COMMAND CAME FROM TTDRV 


IDENTIFIER CODES FOR SYSTEM TO CLI MESSAGES 


ARE RESERVED FOR USE BY DIGITAL 
ARE RESERVED FOR USE BY CUSTOMERS 


;CLI INITIALIZED ENABLED 
;CLI INITIALIZED DISABLED 
;CLI ENABLED 

;CLI DISABLED 

7;CLI BEING ELIMINATED 

7;CLI MUST EXIT IMMEDIATELY 
;NEW TERMINAL LINKED TO CLI 
;TERMINAL REMOVED FROM CLI 
;GENERAL MESSAGE TO CLI 
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000000 
000002 
000004 
000006 
000007 
000010 
000012 

000013 


000014 


000010 
000012 
000014 
000016 
000020 
000022 
000024 
000030 


000032 


000000 
000002 
000004 
000006 
000010 
000012 
000014 
000016 
000020 
000022 


DT 0 we we we 
uno 


A.LENI=. 


-=A.LIN 
A.IMAP: 
A.IBUF: 
A.ILEN: 
A.SMAP: 
A.SBUF: 
A.SLEN: 
A.IOS: 
A.RES: 


A.LEN2=. 


- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKB 
- BLKB 


a 


a eee 


PKTDF$ (Cont.) 


ANCILLARY CONTROL BLOCK (ACB) DEFINITIONS 


;ACD RELOCATION BIAS 
;ACD DISPATCH TABLE POINTER 
;ACD FUNCTION MASK 


:ACD 


IDENTIFICATION NUMBER 


; RESERVED 


;ACD 


LINK WORD 


;ACD ACCESS COUNT 


3; ACD 


STATUS BYTE 


;LENGTH OF PROTOTYPE ACB 


;FULL ACB OVERLAPS PROTOTYPE ACB 


;ACD 
7; ACD 
3; ACD 
;ACD 
;ACD 
; ACD 
;ACD 


INTERRUPT BUFFER RELOCATION BIAS 
INTERRUPT BUFFER ADDRESS 

INTERRUPT BUFFER LENGTH 

SYSTEM STATE BUFFER RELOCATION BIAS 
SYSTEM STATE BUFFER ADDRESS 

SYSTEM STATE BUFFER LENGTH 

I/O STATUS 


;RESERVED FOR USE BY THE ACD 


;LENGTH OF FULL ACB 


+; DEFINE THE FLAG VALUES IN THE OFFSET U.AFLG 


f 

UA.ACC=1 
UA. PRO=2 
UA. ECH=4 


UA. TYP=10 
UA.SPE=20 
UA. PUT=40 
UA. CAL=100 
UA.COM=200 
UA. ALL=400 
UA. TRA=1000 


e =e me me 


=0 
A.ACCE: .~BLKW 
A.DEQU: .~BLKW 
A.POWE: .BLKW 
A.INPU: .~BLKW 
A.OUTP: .BLKW 
A.CONN: .BLKW 
A.DISC: .~BLKW 
A.RECE: .~BLKW 
A.PROC: .BLKW 
A.CALL: .BLKW 


PREP PRP RP Pe ee 


ACCEPT THIS CHARACTER 

;PROCESS THIS CHARACTER 

;ECHO THIS CHARACTER 

;FORCE THIS CHARACTER INTO TYPEAHEAD 
;THIS CHARACTER HAS A SPECIAL ECHO 


;PUT 


THIS CHARACTER IN THE INPUT BUFFER 


;CALL THE ACD BACK AFTER THE TRANSFER 
;COMPLETE THE INPUT REQUEST 

;ALLOW PROCESSING OF THIS I/0 REQUEST 
;TRANSFER CHARS. WHEN I/O COMPLETES 


31/0 
31/0 


DEFINE THE ACD ENTRY POINTS (OFFSETS INTO THE DISPATCH TABLE) 


REQUEST ACCEPTANCE ENTRY POINT 
REQUEST DEQUEUE ENTRY POINT 


;POWER FAILURE ENTRY POINT 

; INPUT COMPLETION ENTRY POINT 

;OUTPUT COMPLETION ENTRY POINT 
;CONNECTION ENTRY POINT 

;DISCONNECTION ENTRY POINT 

7; INPUT CHARACTER RECEPTION ENTRY POINT 
; INPUT CHARACTER PROCESSING ENTRY POINT 
;CALL ACD BACK AFTER TRANSFER ENTRY POINT 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


PKTDFS$ (Cont.) 


; DEFINE THE STATUS BITS IN A.STA OF THE PROTOTYPE ACB 


;ACD IS MARKED FOR DELETE 


; 
AS. DEL=1 
;ACD IS DISABLED 


AS. DIS=2 
-PSECT 


000000 
000004 


000004 
000006 
000010 
000012 
000014 
900016 
000020 
000021 
000022 
000023 
000024 
000026 
000030 
000031 
000032 
000034 
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SCBDF$ 


SCBDF$ ,,SYSDEF 


me we 


STATUS CONTROL BLOCK 


THE STATUS CONTROL BLOCK (SCB) DEFINES THE STATUS OF A DEVICE 
CONTROLLER. THERE IS ONE SCB FOR EACH CONTROLLER IN A SYSTEM. 
THE SCB IS POINTED TO BY UNIT CONTROL BLOCKS. TO EXPAND ON THE 
TELETYPE EXAMPLE ABOVE, EACH TELETYPE INTERFACED VIA A DL11-A 
WOULD HAVE A SCB SINCE EACH DL11-A IS AN INDEPENDENT INTERFACE 
UNIT. THE TELETYPES INTERFACED VIA THE DH11 WOULD ALSO EACH HAVE 
AN SCB SINCE THE DH11 IS A SINGLE CONTROLLER BUT MULTIPLEXES MANY 


=e “Se Se "6 “es Se TO8 TSE Ne Se 


UNITS IN PARALLEL. 
-IF NB SYSDEF 
-ASECT 
S.LHD: .BLKW 2 :;CONTROLLER I/O QUEUE LISTHEAD 
S.URM ;REFERENCE LABEL 
~IF DF MSSPRO 
- BLKW 1 ;UNIBUS RUN MASK FOR THE FORK BLOCK 
~ENDC 
S.FRK: .BLKW 1 ;FORK BLOCK LINK WORD 
. BLKW 1 ; FORK-PC 
. BLKW 1 ; FORK-R5 
. BLKW qi ; FORK-R4 
S.KS5: .BLKW 1 ;FORK KISARS 
S.PKT: .BLKW l ;ADDRESS OF CURRENT I/O PACKET 
S.CTM: .BLKB 1 ;CURRENT TIMEOUT COUNT 
S.ITM: .BLKB 1 ; INITIAL TIMEOUT COUNT 
S.STS: .BLKB 1 ;STATUS (O=FREE, NE O=BUSY) 
S.ST3:  .BLKB 1 ;STATUS EXTENSION BYTE 
S.ST2: .BLKW 1 :;STATUS EXTENSION 
S.KRB: .BLKW 1 ;ADDRESS OF KRB 
S.RCNT: .BLKB ni ;NUMBER OF REGISTERS TO COPY 
S.ROFF: .BLKB 1 ;OFFSET TO FIRST DEV REG TO COPY 
S.EMB: .BLKW 1 sERROR MESSAGE BLOCK POINTER 
S.KTB: .BLKW 1 :START OF MULTI-ACCESS KRBS 
-PSECT 
-IFF 
; 
; STATUS CONTROL BLOCK STATUS EXTENSION BIT DEFINITIONS 
S2.EIP=l s;ERROR IN PROGRESS (1=YES) 
S2.ENB=2 ;ERROR LOGGING ENABLED (0=YES) 
S$2.LOG=4 ;ERROR LOGGING SUPPORTED (1=YES) 
S2.MAD=10 ;MULTIACCESS DEVICE (1=YES) 
S2.LDS=40 ;LOAD SHARING ENABLED (1=YES) 
S2.OPT=100 ;SUPPORTS SEEK OPTIMIZATION (1=YES) 
S$2.CON=200 ;SCB AND KRB ARE CONTIGUOUS (1=YES) 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


SCBDF$ (Cont.) 


$2.0P1=400 
§2.0P2=1000 


S$2.ACT=2000 
$2. XHR=4000 


e ™e me 


$3.DRL=1 
S3.NRL=2 


$3.6] P=4 

S$3.ATN=10 
$3.°£LV=20 
$3.£PA=40 
$3.5PB=100 
53.0OPT=200 


S3.£PU=S3.SPA!S3.SPB 


;THESE TWO BITS DEFINE THE OPTIMIZATION 
;METHOD. 

;O0P2,OP1=0,0 INDICATES NEAREST CYLINDER 
7;OP2,OP1=0,1 INDICATES ELEVATOR 
7OP2,O0P1=1,0 INDICATES C-SCAN 
;0P2,OP1=1,1 RESERVED 

;DRIVER HAS OPERATION OUTSTANDING (1=YES) 
;EXTERNAL HEADER AND NEW I.LN2 SUPPORT 


YTATUS CONTROL BLOCK STATUS EXTENSION (S.ST3) DEFINITIONS 


;MULTI-ACCESS DRIVE IN RELEASED STATE(1=YES) 
;DRIVER SHOULDN'T RLS MULTI-ACCESS DRIVE 
; (L=YES) 

;SEEK IN PROGRESS (1=YES) 

;DRIVER MUST CLEAR ATTENTION BIT (1=YES) 
;DEVICE USES SLAVE UNITS (1=YES) 

;PORT 'A' SPINNING UP 

;PORT 'B' SPINNING UP 

;SEEK OPTIMIZATION ENABLED (1=YES) 

;.OR. OF PORT SPINUP BITS 


KFB ADDRESS TABLE (S.KTB) PORT OFFLINE FROM THIS SCB FLAG. 


; 
; 
KP.CFL=1 


me se NS 


-ASECT 
-=0 

000000 M.LNK: .BLKW 
000002 M.UMRA: .BLKW 
000004 M.UMRN: .BLKW 
000006 M.UMVL: .BLKW 
000010 M.UMVH: .BLKB 
000011 M.BFVH: .BLKB 
000012 M.BFVL: .BLKW 
000014 M.LGTH=. 


- ENDC 


~ PSECT 


et ee ee ee 


;KRB ADDRESS POINTS TO OFFLINE PORT (1=YES) 


MAPPING ASSIGNMENT BLOCK (FOR UNIBUS MAPPING REGISTER ASSIGNMENT) 


; LINK WORD 

;ADDRESS OF FIRST ASSIGNED UMR 

NUMBER OF UMR'S ASSIGNED * 4 

;LOW 16 BITS MAPPED BY 1ST ASSIGNED UMR 
;HIGH 2 BITS MAPPED IN BITS 4 AND 5 
;HIGH 6 BITS OF PHYSICAL BUFFER ADDRESS 
;LOW 16 BITS OF PHYSICAL BUFFER ADDRESS 
;LENGTH OF MAPPING ASSIGNMENT BLOCK 


000000 
000002 
000004 
000010 
000012 
000013 
000014 


000016 


000000 
000002 
000003 
000004 
000005 
000006 
000010 


000060 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


SHDDF$ 


SHDDFS$ 


FIRST, WE MUST DEFINE THE I/O PACKET DEFINITIONS, SINCE WE 
USE THEM IN OUR DEFINITIONS. 


=e “=e Te ME 


PKTDFS ;DEFINE I/O PACKET DEFINITIONS 


SHADOW RECORDING LINKAGE BLOCK (UMB) 


THE UMB LINKS TOGETHER TWO UCB'S AS A SHADOW SET. ONE IS THE 
PRIMARY UCB, THE OTHER THE SECONDARY UCB. THE EXISTANCE OF A 
UMB SIGNALS THAT SHADOW RECORDING IS ENABLED ON A PARTICULAR 
UCB. 


me Te Me TO TH NO MO TWO 


~ASECT 


M.LNK: .BLKW 1 ; LINKAGE OF ALL UMB'S IN THE SYSTEM 
M.LHD: .BLKW 1 ;LISTHEAD OF ALL ML NODES FOR THIS SET 
M.UCB: .BLKW 2 ;PRIMARY AND SECONDARY UCB ADDRESSES 
M.STS: .BLKW 1 ;STATUS WORD 
M.LBN: .BLKB 1 ;HIGH ORDER BYTE OF FENCE 

. BLKB 1 7UNUSED BYTE (MAYBE STATUS?) 

- BLKW 1 ; LOW ORDER WORD OF FENCE 


M.LGH=. 


UMB STATUS BIT DEFINITIONS 


™e te we 


- PSECT 
MS.MDA=1 ;UMB MARKED FOR DEALLOCATION (1=YES) 
MS.CHP=2 ;CATCHUP IN PROGRESS (1=YES) 


=e tO 


DEFINE THE OFFSETS FOR THE ML NODE, LINKED OFF OF THE UMB 
THROUGH CELL M.LHD. THIS NODE CONTAINS THE SECONDARY I/0 
PACKET, AND DOUBLES AS THE ERROR PACKET TO THE ERROR MESSAGE 
TASK. 


me Se tO Ne 


-ASECT 
ML.LNK: .~BLKW 
ML.LEN: .BLKB 
ML.TYP: .BLKB 
ML.DNC: .~BLKB 

- BLKB 
ML.PRI: .BLKW 
ML.PKT: .~BLKB 


;LINKAGE OF ALL ML NODES ON UMB 
; LENGTH OF ML NODE FOR DEALLOCATION 
;TYPE OF ML NODE FOR ERROR TASK 
;DONE COUNT OF PACKETS 
; UNUSED 
; PRIMARY I/O PACKET ADDRESS 

~LGTH ;SECONDARY I/O PACKET 


KS be 


ML.LGH=. 
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SHDDF$ (Cont.) 


ML NODE TYPE CODES 


=e Te MO 


»PSECT 
MT. PKT=1 ;ML NODE IS I/O PACKET TYPE 


I/O PACKET OFFSET DEFNS FOR USE BY SHADOW RECORDING 


™e Me Te 


I.RO=I.PRM ;STATUS STORAGE FOR RO STATUS 
I.R1=I.PRM+2 ;STATUS STORAGE FOR Rl STATUS 


; DEFINE THE ERROR MESSAGE POINTERS THAT RESIDE IN THE I/O PACKET. 
» PSECT 

ML. FID=ML.PKT+I.IOSB ;FILE ID WHICH CONTAINS ERROR 

ML. FSEQ=ML.PKT+I.IOSB+2 ;FILE SEQUENCE NUMBER OF FILE IN ERROR 

ML.LBN=ML.PKT+1I.PRM+10 ;HIGH ORDER LBN OF BLOCK(S) IN ERROR 

ML. CNT=ML. PKT+I.PRM+4 ;NUMBER OF BLOCKS IN BAD XFER 


ML. TCB=ML. PKT+I.TCB ;TCB OF TASK WITH BAD REQUEST 
ML. SRO=ML. PKT+I.RO ;RO OF SECONDARY I/O PACKET 
ML.SR1=ML.PKT+I.R1 7;R1l OF SECONDARY I/O PACKET 


ML.PRO=ML.PKT+I.PRM+14 ;RO OF PRIMARY I/O PACKET 
ML.PRI=ML.PKT+I.PRM+16 ;R1 OF PRIMARY I/O PACKET 


000000 
000002 
000003 
000004 
000006 
000012 
000016 
000022 
000026 
000030 
000032 
000034 
000036 
000040 
000041 
000044 
000046 
000050 
000052 
000054 
000060 
000062 
000063 
000004 
000065 
000066 
000072 


000074 
000076 
000077 
000100 


000104 
000110 


RSX-11M-PLUS 


TASK 


TASK 


=e me "8 0S MO 


-=0 
T.LNK: 
T.PRI: 
TeLOC? 
T.PCBV: 
T.NAM: 
T.RCVL: 
T.ASTL: 
T.EFLG: 
T.UCB: 
T.TCBL: 
T.STAT: 
T.ST2: 
T.ST3: 
T.DPRI: 
T.LBN: 
T.LDV: 
T.PCB: 
T.MXSZ: 
T.ACTL: 
T.ATT: 
T.ST4: 
T.HDLN: 


T.GGF: 
Te TLO% 
T.EFLM: 
T.TKSZ: 


S$$=. 
T.OFF: 
T.SRCT: 
T.RREL: 


-=SSS 


S$$=. 
T.OCBH: 
Te RDCT? 


2=S$S5 


TCBDFS 


CONTROL 
CONTROL 
~-ASECT 


- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKW 
- BLKW 


- BLKW 
- BLKB 
- BLKB 
- BLKW 
-IF NDF 


« ENDC 


-IF NB 


- BLKW 
- BLKW 


-IF NDF 


- ENDC 


SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


1 eo YSDEF 


BLOCK OFFSET AND STATUS DEFINITIONS 


BLOCK 


en NO ee ee NO Oe ae ee ee OO CNC ee 


NPR Re 


PSSLAS 


SYSDEF 


2 
d 


PSSOFF 


; UTILITY LINK WORD 
;TASK PRIORITY 
31/0 PENDING COUNT 


TCBDF$ 


;POINTER TO COMMON PCB VECTOR 


;TASK NAME IN RAD50 

;RECEIVE QUEUE LISTHEAD 

;AST QUEUE LISTHEAD 

;TASK LOCAL EVENT FLAGS 1-32 


;UCB ADDRESS FOR PSEUDO DEVICE 'TI' 


;TASK LIST THREAD WORD 


;FIRST STATUS WORD (BLOCKING BITS) 
;SECOND STATUS WORD (STATE BITS) 
;THIRD STATUS WORD (ATTRIBUTE BITS) 


;TASK'S DEFAULT PRIORITY 
;LBN OF TASK LOAD IMAGE 
;UCB ADDRESS OF LOAD DEVICE 


;PCB ADDRESS OF TASK PARTITION 


;MAXIMUM SIZE OF TASK IMAGE (MAPPED ONLY) 


;ADDRESS OF NEXT TASK IN ACTIVE LIST 
;ATTACHMENT DESCRIPTOR LISTHEAD 


;FOURTH TASK STATUS WORD 
; LENGTH OF HEADER 


; UNUSED 


(0 IF HDR IN POOL) 


;GROUP GLOBAL USE COUNT FOR TASK 
;BUFFERED I/O IN PROGRESS COUNT 


;TASK WAITFOR MASK/ADDRESS 


;TASK LOAD SIZE IN 32 WD BLOCKS 


;MARK START OF PLAS AREA 


;OFFSET TO TASK IMAGE IN PARTITION 


;RESERVED 


;SREF WITH EFN COUNT IN ALL RECEIVE QUEUES 


;RECEIVE BY REFERENCE LISTHEAD 


;MOVE LC BACK TO START OF PLAS AREA 


;MARK START OF PARENT/OFFSPRING AREA 
;OFFSPRING CONTROL BLOCK LISTHEAD 
;OUTSTANDING OFFSPRING AND VT: COUNT 
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TCBDF$ (Cont.) 


000112 


T.cAST: 


SSS=. 

T.RRM: 
T.IRM: 
T.CPU: 


2=SS$ 


$$$=. 
T.ACN: 


2=S9S$ 


$$$=. 
T.ISIZ: 


-=SS$ 


- BLKW 1 
.- BLKW 1 
» BLKW a 
- BLKB aN 
- BLKB 1 


-IF NDF MSSPRO 


- ENDC 


- BLKW 1 
-IF NDF ASSCNT 


- ENDC 


. BLKW i 
-IF NDF USSDAS 


- ENDC 


T.LGTH=. 


T.EXT=0 


e =e Se ™e MO 


TS. EXE= 
TS.RDN= 
TS.MSG= 
TS.CIP= 


TS. RUN= 
TS.STP= 
TS.CKR= 


TS.BLC= 


=e "=e Me 


TS.BLK= 


olPF 


100000 
40000 
20000 
10000 


4000 
1000 
100 


a 


177777 


;SPECIFY AST LIST HEAD 


;REQUIRED RUN MASK 
; INITIAL RUN MASK SET UP BY INSTALL 
; PROCESSOR NUMBER ON WHICH TASK LAST EXECUTD 


; (UNUSED) 


;POINTER TO ACCOUNTING BLOCK 


;SIZE OF ROOT I SPACE 


;LENGTH OF TASK CONTROL BLOCK 
;LENGTH OF TCB EXTENSION 


TASK STATUS DEFINITIONS 


FIRST STATUS WORD (BLOCKING BITS) 


;TASK NOT IN EXECUTION (1=YES) 

71/0 RUN DOWN IN PROGRESS (1=YES) 

;ABORT MESSAGE BEING OUTPUT (1=YES) 

;TASK BLOCKED FOR CHECKPOINT IN PROGRESS 

3; (1=YES) 

;TASK IS RUNNING ON ANOTHER PROCESSOR(1=YES) 
;TASK BLOCKED BY CLI COMMAND 

;TASK HAS CKP REQUEST (MP SYSTEM ONLY) 

; (1=YES) 

; INCREMENT BLOCKING COUNT MASK 


TASK BLOCKING STATUS MASK 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITLUND 


TCBDF$ (Cont.) 


e 
s 
e 
a 


SECOND STATUS WORD (STATE BITS) 


T2.AST=100000 , ;AST IN PROGRESS (1=YES) 
T2.DST=40000 ;AST RECOGNITION DISABLED (1=YES) 
T2.CHK=20000 ;TASK NOT CHECKPOINTABLE (1=YES) 
T2.REX=10000 ;REQUESTED EXIT AST SPECIFIED 
T2.SEF=4000 ;TASK STOPPED FOR EVENT FLAG(S) (1=YES) 
T2.SI0=1000 ;TASK STOPPED FOR BUFFERED I/0 
T2.AFF=400 ;TASK IS INSTALLED WITH AFFINITY 
T2.HLT=200 ;TASK IS BEING HALTED (1=YES) 
T2.ABO=100 ;TASK MARKED FOR ABORT (1=YES) 
T2.STP=40 ;SAVED T2.SPN ON AST IN PROGRESS 
T2.STP=20 ;TASK STOPPED (1=YES) 

T2.SPN=10 ;SAVED T2.SPN ON AST IN PROGRESS 
T2.SPN=4 ;TASK SUSPENDED (1=YES) 

T2.WFR=2 ;SAVED T2.WFR ON AST IN PROGRESS 
T2.WFR=1 ;TASK IN WAITFOR STATE (1=YES) 


; 
; THIRD STATUS WORD (ATTRIBUTE BITS) 


td 

T3.ACP=100000 s;ANCILLARY CONTROL PROCESSOR (1=YES) 

T3. PMD=40000 ;DUMP TASK ON SYNCHRONOUS ABORT (0=YES) 

T3. REM=20000 :;REMOVE TASK ON EXIT (1=YES) 

T3.PRV=10000 ;TASK IS PRIVILEGED (1=YES) 

T3.MCR=4000 ;TASK REQUESTED AS EXTERNAL MCR FUNCT(1=YES) 
T3.SLV=2000 ;TASK IS A SLAVE TASK (1=YES) 

T3.CLI=1000 ;TASK IS A COMMAND LINE INTERPRETER (1=YES) 
T3.RST=400 ;TASK IS RESTRICTED (1=YES) 

T3.NSD=200 :;TASK DOES NOT ALLOW SEND DATA 

T3.CAL=100 ;TASK HAS CHECKPOINT SPACE IN TASK IMAGE 
T3.ROV=40 ;TASK HAS RESIDENT OVERLAYS 

T3.NET=20 ;NETWORK PROTOCOL LEVEL 

T3.MPC=10 ;MAPPING CHANGE WITH OUTSTANDING 1/0 (1=YES) 
T3.CMD=4 ;TASK IS EXECUTING A CLI COMMAND 

T3.SWS=2 ;RESERVED FOR SOFTWARE SERVICES USE 
T3.GFL=1 ;GROUP GLOBAL EVENT FLAG LOCK 


STATUS BIT DEFINITIONS FOR FOURTH STATUS WORD (T.ST4) 


e =e ™e 


a 

T4,.MUT=40 ;TASK IS A MULTI-USER TASK 

T4.LDD=20 ;TASK'S LOAD DEVICE HAS BEEN DISMOUNTED 

T4. PRO=10 ;TCB IS (OR SHOULD BE) A PROTOTYPE 

T4.PRV=4 ;TASK WAS PRIV, BUT HAS CLEARED T3.PRV 
;WITH GIN (MAY RESET WITH GIN IF T4.PRV SET) 

T4. DSP=2 ;TASK WAS BUILT FOR USER I/D SPACE 

T4,SNC=1 ;TASK USES COMMONS FOR SYNCHRONIZATION 


; 
; REQUIRED RUN MASK 


TR.UBT=100000 ;UNIBUS RUN T 
TR.UBS=40000 ;UNIBUS RUN S 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


TCBDF$ (Cont.) 


TR.UBR=20000 
TR.UBP=10000 
TR. UBN=4000 
TR. UBM=2000 
TR. UBL=1000 
TR. JBK=400 
TR. UBJ=200 
TR. UBH=100 
TR. JBF=40 
TR. JBE=20 
TR. CPD=10 
TR.CPC=4 

TR. CPB=2 
TR.CPA=1 


- ENDC 


-PSECT 


; UNIBUS RUN 
; UNIBUS RUN 
; UNIBUS RUN 
; UNIBUS RUN 
; UNIBUS RUN 
; UNIBUS RUN 
; UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;UNIBUS RUN 
;PROCESSOR D 
;PROCESSOR C 
; PROCESSOR B 
; PROCESSOR A 


AMyMmanr say Dy 


177772 
177774 
177776 
000000 
000002 
000004 
000005 
000006 
000007 
000010 
000012 
000014 
000016 
000020 
000022 
000024 
000026 
000030 


000032 
000034 
000036 
000034 
000040 
000042 
000046 
000050 
000054 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


UCBDF$ 


UCBDF$ ,,TTDEF,SYSDEF 


UNIT CONTROL BLOCK 


THE UNIT CONTROL BLOCK (UCB) DEFINES THE STATUS OF AN INDIVIDUAL 
DEVICE UNIT AND IS THE CONTROL BLOCK THAT IS POINTED TO BY THE 
FIRST WORD OF AN ASSIGNED LUN. THERE IS ONE UCB FOR EACH DEVICE 
UNIT OF EACH DCB. THE UCB'S ASSOCIATED WITH A PARTICULAR DCB ARE 
CONTIGUOUS IN MEMORY AND ARE POINTED TO BY THE DCB. UCB'S ARE 
VARIABLE LENGTH BETWEEN DCB'S BUT ARE OF THE SAME LENGTH FOR A 
SPECIFIC DCB. TO FINISH THE TELETYPE EXAMPLE ABOVE, EACH UNIT ON 
BOTH INTERFACES WOULD HAVE A UCB. 


me me Me MO MO MO Me MB WS MO MO Me 


-ASECT 
-=177772 

-IF NB SYSDEF 

-IF DF ASSCNT 
~=177770 
U.UAB: .BLKW 1 ;POINTER TO USER ACCOUNT BLOCK 

~IFF 
U.UAB: 

. ENDC 

- ENDC 
U.MUP: .BLKW 1 ;MULTI-USER PROTECTION WORD 
U.LUIC: .BLKW 1 ; LOGIN UIC ~ MULTI USER SYSTEMS ONLY 
U.OWN: .BLKW 1 ;OWNING TERMINAL — MULTI USER SYSTEMS ONLY 
U.DCB: .BLKW 1 ;BACK POINTER TO DCB 
U.RED: .BLKW 1 ;POINTER TO REDIRECT UNIT UCB 
U.CTL:  .BLKB i ;CONTROL PROCESSING FLAGS 
U.STS:  .BLKB l ;UNIT STATUS 
U.UNIT: .BLKB 1 ; PHYSICAL UNIT NUMBER 
U.ST2:  .BLKB 1 ;UNIT STATUS EXTENSION 
U.CWl: .BLKW ad ;FIRST DEVICE CHARACTERISTICS WORD 
U.CW2: .BLKW 1 ;SECOND DEVICE CHARACTERISTICS WORD 
U.CW3: .BLKW l :;THIRD DEVICE CHARACTERISTICS WORD 
U.CW4: .BLKW 1 ;FOURTH DEVICE CHARACTERISTICS WORD 
U.SCB: .BLKW 1: ; POINTER TO SCB 
U.ATT: .BLKW 1 ;TCB ADDRESS OF ATTACHED TASK 
U.BUF: .BLKW i ;RELOCATION BIAS OF CURRENT I/O REQUEST 

. BLKW 1 ;BUFFER ADDRESS OF CURRENT I/O REQUEST 
U.CNT: .BLKW 1 ;BYTE COUNT OF CURRENT I/O REQUEST 
U.UCBX=U.CNT+2 ;POINTER TO UCB EXTENSION IN SECONDARY POOL 
U.ACP=U.CNT+4 ;ADDRESS OF TCB OF MOUNTED ACP 
U.VCB=U.CNT+6 ;ADDRESS OF VOLUME CONTROL BLOCK | 
U.CBF=U.CNT+4 ;CONTROL BUFFER RELOCATION AND ADDRESS 
U.UMB=U.CNT+10 ;ADDRESS OF UMB FOR SHADOW RECORDING 


U.PRM=U.CNT+412 
U.UTMO=U.CNT+16 
U.LHD=U.CNT+20 
U.BPKT=U.CNT+24 


;DISK SIZE PARAMETER WORDS 

; UNIT COMMAND TIME OUT 

; UNIT OUTSTANDING I/O PACKET LISTHEAD 
; UNIT BAD BLOCK PACKET WAITING LIST 
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UCBDF$ (Cont.) 


000060 
000062 
000064 


000040 
000042 
000044 


000000 
000022 
000026 
000032 
000033 
000034 
000035 
000036 


000042 
000046 
000050 
000051 
000051 
000052 
000054 
000055 


000056 


000000 
000002 
000004 
000010 
000020 
000024 


;POINTER TO 2ND EXTENSION IN SECONDARY POOL 
; OUTSTANDING COMMAND STATUS REQUEST REGISTER 
;COMMAND STATUS PROGRESS REGISTER 


U.UC2X=U.CNT+30 
U.OTRF=U.CNT+32 
U.CMST=U.CNT+34 


MAGTAPE DEVICE DEPENDANT UCB OFFSETS 


=e =e %e 


U.SNUM=U.CNT+10 
U.FCDE=U.CNT+12 
U.KRB1=U.CNT+1 4 


;SLAVE UNIT NUMBER 
;FUNCTION CODE 
;SUBCONTROLLER KRB1 POINTER 


e 

; DEFINE SECONDARY POOL UCB EXTENSION OFFSETS 
; (ERROR LOGGING DEVICES ONLY) 
; 


- BLKW 9. ;FIXED ACCOUNTING TRANSACTION HEADER 
X.NAME: .BLKW 2 ;DRIVE NAME IN RAD50 
X.10C: .BLKW 2 71/0 COUNT 
X.ERHL: .BLKB 1 ;HARD ERROR LIMIT 
X.ERSL: .~BLKB iE ;SOFT ERROR LIMIT 
X.ERSC: .BLKB 1 ;SOFT ERROR COUNT 
X.ERHC: .BLKB 1 ;HARD ERROR COUNT 
X.WCNT: .BLKW 2 ;WORDS TRANSFERED COUNT 


we me Me 


DEFINE OFFSETS FOR SEEK OPTIMIZATION DEVICES 


X.CYLC: .BLKW 2 ;CYLINDERS CROSSED COUNT 
X.CCYL: .BLKW 1 ;CURRENT CYLINDER 
X.FCUR: .BLKB 1 ;CURRENT FAIRNESS COUNT 
X.FLIM: ;FAIRNESS COUNT LIMIT 
X-DSKD: .BLKB a ;DISK DIRECTION (HIGH BIT 1=OUT) 
X.DNAM: .BLKW 1 ;DEVICE NAME FOR ACCOUNTING 
X.-UNIT: .BLKB 1 ; UNIT NUMBER FOR ACCOUNTING 

- BLKB i ;UNUSED FOR NOW 
X.LGTH=. ;LENGTH OF THE UCB EXTENSION 
X.0DFFL=10. ;DEFAULT FAIRNESS COUNT LIMIT 
X.DFSL=8. ;DEFAULT SOFT ERROR LIMIT 
X.DFHL=5. ;DEFAULT HARD ERROR LIMIT 


; DEFINE OFFSETS FOR DISK MSCP CONTROLLERS (SECOND UCB EXTENSION) 


X.MLUN: 
X.UNFL: 
X.HSTI: 
X.UNTI: 
X.MEDI: 
X. ‘SHUN: 


- BLKW 
- BLKW 
. BLKW 
- BLKW 
- BLKW 
- BLKW 


FPN & NF Fe 


; CHARACTERISTICS OBTAINED FROM "GET UNIT STATUS" END PACKETS 


s;MULTI-UNIT CODE 

; UNIT FLAGS 

;HOST IDENTIFIER 

;UNIT IDENTIFIER 

;MEDIA IDENTIFIER 
;SHADOW UNIT 


A-66 


000026 
000030 
000032 
000034 
000040 
000042 
000043 


000044 
000050 


000054 


000024 
000026 
000034 


000034 


000035 
000036 
000040 
000041 
000042 
000044 
000045 
000046 
000047 
000050 
000052 
000054 
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X.SHST: .~BLKW 
X.TRCK: .~BLKW 
X.GRP: .BLKW 
X.CYL: .BLKW 
X.RCTS: .~BLKW 
X.RBNS: .BLKB 
X.RCTC: .BLKB 


;SHADOW UNIT STATUS 
;UNIT TRACK SIZE 

; UNIT GROUP SIZE 
;UNIT CYLINDER SIZE 
;UNIT RCT TABLE SIZE 
;UNIT RBN 'S / TRACK 
; UNIT RCT COPIES 


HRN RH BH 


CHARACTERISTICS OBTAINED FROM "ONLINE" OR "SET UNIT 
CHARACTERISTICS" END PACKETS 


me Te te Ne 


X.UNSZ: .~BLKW 2 ;UNIT SIZE 
X.VSER: .~BLKW 2 ; VOLUME SERIAL NUMBER 
X.DUSZ=. ;SIZE OF DISK MSCP CONTROLLER UCB EXTENTION 


-IF NB TTDEF 


U.TUX: .BLKW 
U.TSTA: .BLKW 
U.TTAB: .BLKW 


;POINTER TO UCB EXTENSION (UCBX) 
;STATUS TRIPLE-WORD 


Hwee 


AHEAD BUFFER, CURRENTLY EMPTY 


IF NON-O AND EVEN: POINTER TO MULTI- 
CHARACTER TYPE-AHEAD BUFFER 
o=e-2 


U.TECO: .BLKB 1 


MR 
YPEAHEAD BUFFER SIZE 
EFAULT UIC 


T 
T 
E 
I 
U 
U.TBSZ: .BLKB T 
D 
LINES PER PAGE 
r 
F 
C 
C 
T 
M 


U.UIC: .BLKW 
U.TLPP: .BLKB 
U.TFRQ: .BLKB 
U.TFLK: .BLKW 
U.TCHP: .BLKB 
U.TCVP: .BLKB 
U.TTYP: .BLKB 
U.TMTI: .BLKB 
U.ACB: .BLKW 
U.AFLG: .BLKW 
U.ADMA: .BLKW 


ORK REQUEST BYTE 

ORK LIST LINK WORD 

URRENT HORIZONTAL POSITION 

URRENT VERTICAL POSITION 

ERMINAL TYPE 

ODEM TIMER 

;ANCILLARY CONTROL DRIVER BLOCK ADDR 
; ANCILLARY CONTROL DRIVER FLAGS WORD 
; ANCILLARY CONTROL DRIVER DMA BUFFER 


@ =e ™e ™e Ne M8 MO Me Ne MO Me Me MO Ne MO Me Me MO NO NO 


a ed 


DEFINE BITS IN STATUS WORD 1 (U.TSTA) 


eo =e te 


a 

S1.RST=1 ;READ WITH SPECIAL TERMINATORS IN PROGRESS 
S1.RUB=2 ;RUBOUT SEQUENCE IN PROGRESS (NON-SCOPE) 
S1.ESC=4 ;ESCAPE SEQUENCE IN PROGRESS 


;IF O: U.TTAB+1 IS SINGLE-CHARACTER TYPE- 


IF ODD: U.TTAB+1 IS SINGLE-CHARACTER TYPE- 
AHEAD BUFFER AND HOLDS A CHARACTER 


HE NEXT TWO OFFSETS OVERLAP U.TTAB WHEN 
HE TYPEAHEAD BUFFER IS IN SECONDARY POOL 
CHO BUFFER FOR DMA OPERATIONS WHEN UCBX IS 
N SECONDARY POOL AND THUS NOT MAPPED BY A 


RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS 


UCBDF$ (Cont.) 


S1.RAL=10 
S1.RNE=20 
S$1.CTO=40 
S1.OBY=100 
S1.IBY=200 
S1.BEL=400 
S1.DPR=1000 
S1.DEC=2000 
S51.DSI=4000 
51.CTS=10000 
S1.UST=20000 
S1.OBF=40000 
S1.IBF=100000 


° 
c 


; DEFINE BITS IN STATUS 


S2.ACR=1 
S2.WRA=6 
S2.WRB=2 
S2.CR=10 
S2.BRQ=20 
S2.SRQ=40 


S2.O0ORQ=100 
S2.I1RQ=200 
S2.HFL=3400 
S2.VFL=4000 
S2.HHT=10000 
S$2.HFF=20000 
S52. FLF=40000 
52. FDX=100000 


; DEFINE BITS IN STATUS 


; 
S3.RAL=10 


S$3.RPO=20 
S3.WES=40 
$3. TAB=100 
53. 8BC=200 
S3.RCU=400 
S3.ABD=1000 
$3.ABP=2000 
S3.WAL=4000 
S3.VER=10000 


S$3.BCC=20000 


S3.DA0=40000 


S3.PCU=100000 


- ENDC 


;READ ALL IN PROGRESS 
;ECHO SUPPRESSED 

;OUTPUT STOPPED BY CTRL-O 

;OUTPUT BUSY 

; INPUT BUSY 

;BELL PENDING 

;DEFER PROCESSING OF CHAR. IN U.TECB 
;DEFER ECHO OF CHAR. IN U.TECB 

; INPUT PROCESSING DISABLED 

;OUTPUT STOPPED BY CTRL-S 

; UNSOLICITED INPUT IN PROGRESS 
;BUFFERED OUTPUT IN PROGRESS 
;BUFFERED INPUT IN PROGRESS 


WORD 2 (U.TSTA+2) 


;WRAP-AROUND (AUTOMATIC CR-LF) REQUIRED 
;CONTEXT FOR WRAP-AROUND 

;LOW BIT IN S2.WRA BIT PATTERN 
;TRAILING CR REQUIRED ON OUTPUT 

; BREAK-THROUGH-WRITE REQUEST IN QUEUE 
;SPECIAL REQUEST IN QUEUE 

;(I1O.ATT, IO.DET, SF.SMC) 

;OUTPUT REQUEST IN QUEUE (MUST = S1.OBY) 
; INPUT REQUEST IN QUEUE (MUST = S1.IBY) 
;HORIZONTAL FILL REQUIREMENT 

;VERTICAL FILL REQUIREMENT 

;HARDWARE HORIZONTAL TAB PRESENT 
;HARDWARE FORM-FEED PRESENT 

;FORCE LINE FEED BEFORE NEXT ECHO 

;LINE IS IN FULL DUPLEX MODE 


WORD 3 (U.TSTA+4) 


; TERMINAL IS IN READ-PASS-ALL MODE 
;(S3.RAL MUST = S1.RAL) 

;READ W/PROMPT OUTPUT IN PROGRESS 

;TASK WANTS ESCAPE SEQUENCES 

;TYPE-AHEAD BUFFER ALLOCATION REQUESTED 
;PASS 8 BITS ON INPUT 

;RESTORE CURSOR (MUST = TF.RCU*400) 
;AUTO-BAUD SPEED DETECTION ENABLED 
;AUTO-BAUD SPEED DETECTION IN PROGRESS 
;WRITE-PASS-ALL (MUST = TF.WAL*400) 
;LAST CHAR. IN TYPE-AHEAD BUFFER 

;HAS PARITY ERROR 

;LAST CHAR. IN TYPE-AHEAD BUFFER 

;HAS FRAMING ERROR 

;LAST CHAR. IN TYPE-AHEAD BUFFER 

;HAS DATA OVERRUN ERROR 

;NOTE - THE 3 BITS ABOVE MUST CORRESPOND 
;TO THE RESPECTIVE ERROR FLAGS IN THE 
;HARDWARE RECEIVE BUFFER 

:POSITION CURSOR BEFORE WRITE 
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000006 


000024 
000026 
000030 
000032 
000034 


000040 


000026 
000030 
000034 


UCBDF$ (Cont.) 


; 
7 VIRTUAL TERMINAL UCB DEFINITIONS 
; 


=U.UNIT 
U.OCNT: .BLKB 


-=U.BUF 

U.RPKT: .~BLKW 
U.WPKT: .~BLKW 
U.IAST: .BLKW 
YU.OAST: .~BLKW 
U.AAST: .~BLKW 


-IF NB 


-IITF NE U.AAST+2-U.UIC 


- ENDC 


-=U.AAST+4 
U.PTCB: .BLKW 


1 


a 


TTDEF 


1 


;OFFSPRING WITH THIS AS TI: 


;CURRENT OFFSPRING READ I/O PACKET 
;CURRENT OFFSPRING WRITE I/O PACKET 
; INPUT AST ROUTINE ADDRESS 

;OUTPUT AST ROUTINE ADDRESS 

;ATTACH AST ROUTINE ADDRESS 


-ERROR ;ADJACENCY ASSUMED 


; PARENT TCB ADDRESS 


; CONSOLE DRIVER DEFINITIONS 


=U.BUF+2 

U.CTCB: .~BLKW 
U.COTQ: .~BLKW 
U.RED2: .~BLKW 


-PSECT 


© 30 Me Me Ne 


DV.REC=1 
DV.CCL=2 
DV. TTY=4 
DV.DIR=10 
DV.SDI=20 
DV.SQD=40 
DV.MSD=100 
DV. UMD=200 
DV.MBC=400 
DV. EXT=400 


DV. SWL=1000 
DV. ISP=2000 
DV. OSP=4000 
DV. PSE=10000 
DV. COM=20000 
DV. F11=40000 
DV.MNT=100000 


;ADDRESS OF CONSOLE LOGGER TCB 
71/0 PACKET LIST QUEUE 
;REDIRECT UCB ADDRESS 


DEVICE TABLE STATUS DEFINITIONS 


DEVICE CHARACTERISTICS WORD 1 (U.CW1l) DEVICE TYPE DEFINITION BITS. 


;RECORD ORIENTED DEVICE (1=YES) 
;CARRIAGE CONTROL DEVICE (1=YES) 

;TERMINAL DEVICE (1=YES) 

;FILE STRUCTURED DEVICE (1=YES) 

;SINGLE DIRECTORY DEVICE (1=YES) 
;SEQUENTIAL DEVICE (1=YES) 

;MASS STORAGE DEVICE (1=YES) 

;USER MODE DIAGNOSTICS SUPPORTED (1=YES) 
;MASSBUS CONTROLLER (11M COMPATIBILITY ONLY) 
;UNIT ON EXTENDED 22-BIT UNIBUS CNTROLER 

; (1=YES) 

;UNIT SOFTWARE WRITE LOCKED (1=YES) 

; INPUT SPOOLED DEVICE (1=YES) 

;OUTPUT SPOOLED DEVICE (1=YES) 

;PSEUDO DEVICE (1=YES) 

;DEVICE IS MOUNTABLE AS COM CHANNEL (1=YES) 
;DEVICE IS MOUNTABLE AS Fll DEVICE (1=YES) 
;DEVICE IS MOUNTABLE (1=YES) 
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° 
s 


° 
td 


U2.DH1=100000 


U2.DJ1=40000 
U2. RMT=20000 
U2. HFF=10000 
U2. L8S=10000 
U2.NEC=4000 
U2.CRT=2000 
U2. ESC=1000 
U2. LOG=400 
U2.SLV=200 
U2.DZ1=100 
U2.HLD=40 
U2.AT.=20 
U2. PRV=10 
U2.L3S=4 

U2. VT5=2 

U2. LWC=1 


TERMINAL DEPENDENT CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 


;UNIT IS A MULTIPLEXER (1=YES) 
;UNIT IS A DJll (1=YES) 

;UNIT IS REMOTE (1=YES) 

;UNIT HANDLES HARDWARE FORM FEEDS (1=YES) 
;OLD NAME FOR U2.HFF 

;DON'T ECHO SOLICITED INPUT (1=YES) 

;UNIT IS A CRT (1=YES) 

;UNIT GENERATES ESCAPE SEQUENCES (1=YES) 
;USER LOGGED ON TERMINAL (0=YES) 

;UNIT IS A SLAVE TERMINAL (1=YES) 

;UNIT IS A DZ1l (1=YES) 

; TERMINAL IS IN HOLD SCREEN MODE (1=YES) 
;MCR COMMAND AT. BEING PROCESSED (1=YES) 
;UNIT IS A PRIVILEGED TERMINAL (1=YES) 
;UNIT IS A LA30S TERMINAL (1=YES) 

;UNIT IS A VTO5B TERMINAL (1=YES) 

; LOWER CASE TO UPPER CASE CONVERSION (0=YES) 


; BIT DEFINITIONS FOR U.MUP 


UM. OVR=1 
UM.CLI=36 
UM.DSB=200 
UM.NBR=400 
UM.CNT=1000 
UM. CMD=2000 
UM. SER=4000 
UM. KIL=10000 


- TAPR=24 
- TTBF=46 


CH Coxe se Se we 


Coste se we 


2.R04=100000 


;OVERRIDE CLI INDICATOR 
;CLI INDICATOR BITS 

;TERMINAL DISABLED SINCE CLI ELIMINATED 
;NO BROADCAST 

;CONTINUATION LINE IN PROGRESS 

;COMMAND IN PROGRESS 

;SERIAL COMMAND RECOGNITION ENABLED 
;TTDRV SHOULD SEND KILL PKT ON CNTRL/C 


TERMINAL SECONDARY POOL OFFSETS FOR THE UCB EXTENSION AND TYPE- 
AHEAD BUFFER 


;OFFSET WITHIN UCB WHICH POINTS TO UCB EXT 
;OFFSET WITHIN UCB EXTENSION WHICH POINTS TO 
;TYPEAHEAD BUFFER 


RH11-RS03/RS04 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 


;UNIT IS A RSO4 (1=YES) 


; RH11-TU16 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 


U2. 7CH=10000 


;UNIT IS A 7 CHANNEL DRIVE (1=YES) 


; TERMINAL DEPENDENT CHARACTERISTICS WORD 3 (U.CW3) BIT DEFINITIONS 


U3.UPC=20000 


; UPCASE OUTPUT FLAG 
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VIRTUAL TERMINAL 3RD CHARACTERISTICS WORD DEFINITIONS 


; 
U3. FDX=1 ;FULL DUPLEX MODE (1=YES) 

U3. DBF=2 ; INTERMEDIATE BUFFERING DISABLED (1=YES) 
U3.RPR=4 ;READ W/PROMPT IN PROGRESS (1=YES) 

: 

; TERMINAL DEPENDENT CHARACTERISTICS WORD 4 (U.CW4) BIT DEFINITIONS 
; 

U4.CR=100 ;LOOK FOR CARRIAGE RETURN 


; 
7; UNIT CONTROL PROCESSING FLAG DEFINITIONS 


t 

UC. ALG=200 ;BYTE ALIGNMENT ALLOWED (1=NO) 
UC.NPR=100 ;DEVICE IS AN NPR DEVICE (1=YES) 

UC. QUE=40 ;CALL DRIVER BEFORE QUEUING (1=YES) 

UC. PWF=20 ;CALL DRIVER AT POWERFAIL ALWAYS (1=YES) 
UC. ATT=10 ;CALL DRIVER ON ATTACH/DETACH (1=YES) 
UC. KIL=4 ;CALL DRIVER AT I/O KILL ALWAYS (1=YES) 
UC. LGH=3 ; TRANSFER LENGTH MASK BITS 


° 
‘ 
e 
e 


UNIT STATUS BIT DEFINTIONS 


‘ 

US.BSY=200 ;UNIT IS BUSY (1=YES) 

US.MNT=100 ;UNIT IS MOUNTED (0=YES) 

US. FOR=40 ;UNIT IS MOUNTED AS FOREIGN VOLUME (1=YES) 

US .MDM=20 ;UNIT IS MARKED FOR DISMOUNT (1=YES) 

7 

; CARD READER DEPENDENT UNIT STATUS BIT DEFINITIONS 

; 

US.ABO=1 ;UNIT IS MARKED FOR ABORT IF NOT READY 
7; (1=YES) 

US.MDE=2 ;UNIT IS IN 029 TRANSLATION NODE (1=YES) 


FILES-11 DEPENDENT UNIT STATUS BITS 


™=e te M8 


US.WCK=10 ;WRITE CHECK ENABLED (1=YES) 
US.SPU=2 ;UNIT IS SPINNING UP (1=YES) 
US.VV=1 ; VOLUME VALID IS SET (1=YES) 


; TERMINAL DEPENDENT UNIT STATUS BIT DEFINITIONS 


; 

US.CRW=4 ;UNIT IS WAITING FOR CARRIER (1=YES) 

US. DSB=2 ;UNIT IS DISABLED (1=YES) 

US.OIU=1 ;OUTPUT INTERRUPT IS UNEXPECTED ON UNIT 
7 (1=YES) 
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LPS11 DEPENDENT UNIT STATUS BIT DEFINITIONS 


=e "es MO 


US. FRK=2 ;FORK IN PROGRESS (1=YES) 
US.SHR=1 ;SHAREABLE FUNCTION IN PROGRESS (0=YES) 


ANSI MAGTAPE DEPENDANT UNIT STATUS BITS 


S.LAB=4 ;UNIT HAS LABELED TAPE ON IT (1=YES) 


Ci we we Ne 


. 
‘ 


; UNIT STATUS EXTENSION (U.ST2) BIT DEFINITIONS 


US.OFL=1 ;UNIT OFFLINE (1=YES) 

US. RED=2 ;UNIT REDIRECTABLE (0=YES) 

US. PUB=4 ;UNIT IS PUBLIC DEVICE (1=YES) 

US.UMD=10 ;UNIT ATTACHED FOR DIAGNOSTICS (1=YES) 

US. PDF=20 ;PRIVILEGED DIAGNOSTIC FUNCTIONS ONLY (1=YES) 


MAGTAPE DENSITY SUPPORT DEFINITION IN U.CW3 


/ 


UD. UNS=0 ; UNSUPPORTED 

UD. 200=1 ; 200BPI, 7 TRACK 

UD. 556=2 7 SSO6BPI, 7 TRACK 

UD. 800=3 ; 800BPI, 7 OR 9 TRACK 
UD. 160=4 ;1600BPI, 9 TRACK 
UD.625=5 76250BPI, 9 TRACK 


APPENDIX B 


CONVERTING A USER-SUPPLIED RSX-11M DRIVER 


This appendix describes the modifications that you must make to enable 
an RSX-11M user-supplied driver to run on an RSX-l1M-PLUS system. The 
modifications involve both the driver data base and the driver code. 


B.1 ASSUMPTIONS AND GENERAL APPROACH 


The discussion in this appendix assumes that the RSX-11M user-supplied 
driver runs on a mapped system. Also, samples of code from the 
RLO1/RLO2 driver (DLDRV) are used as examples in this appendix. 


As a general approach to converting a driver, proceed in the following 
manner: 


1. Read the RSX-11M-PLUS Guide to Writing an I/O Driver to gain 
a feeling for the differences between RSX-11M_ and 
RSX-11M-PLUS drivers. Note especially the differences in the 
data structures (RSX-11M-PLUS has two additional structures). 


2. Make the changes described in this appendix. 


3. Incorporate the driver according to the guidelines given in 
Chapter 5. 


For the purposes of this discussion, a standard disk driver is one 
that does not attempt to use any of the advanced driver features that 
are described in Chapter l. 


B.2 MODIFYING THE DATA BASE CODE 


Before creating the driver data base, read the overview of programming 
user-written driver data bases (Section 4.2). It gives important 
information on ordering and labeling in the code. 
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B.2.1 Unit Control Block Changes 


Ensure that the Unit Control Block (UCB) has the data needed for disk 
geometry calculations. Refer to the description of U.PRM in Section 
4.4.4. The following is an example of the code needed to store the 


disk geometry: 


~BYTE 40.,2 ;U.PRM 
-WORD on hea ;U.PRM+2 


Notes: 
l. 40. indicates the number of sectors per track. 
2. 2 indicates the number of tracks per cylinder. 
3. 512. indicates the number of cylinders per volume. 


4. The values in the code are device dependent. 


B.2.2 Status Control Block Changes 


RSX-1L1IM-PLUS requires a structure called the Controller Request Block 
(KRB). You can add the KRB data that RSX-11M-PLUS requires to the 
Status Control Block (SCB) data to effectively create one continuous 
structure. This arrangement is called the contiguous KRB/SCB and is 
described in Sections 4.2.4 and 4.4.7. Because the ordering of the 
SCB data differs from RSX-11M to RSX-11M-PLUS, you must rearrange the 
RSX-11M SCB data to accommodate the RSX-l11M-PLUS requirements. Lt 
your driver refers to the SCB structures by symbolic offset and does 
not rely on physical ordering, you do not need to change the driver 
code that accesses the SCB. Refer to Sections 4.4.5 and 4.4.6 for a 
description of the offsets required. 


There must be one KRB/SCB combination for each controller present on 
the system. 


An example of code that includes the proper offsets appears in Figure 
B-l. 
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BYTE PR5,160/4 ;K.PRI,K.VCT 
-BYTE 0*2,0 ;K.CON,K.I0C 
-WORD- KS.OFL ;K.STS 
SDLA:: ;START OF KRB 
-WORD 174400 ;K.CSR 
-WORD DLA-SDLA ;K.OFF 
-BYTE 0,0 ;K.HPU 
«WORD - DLO ;K.OWN 
SDLO:: ;START OF CONTIGUOUS SCB 
-WORD 0,.-2 ;S.LHD/K.CRQ 
-WORD  0,0,0,0 3S.FRK 
-WORD 0 3S.KS5 
-WORD 0 ;S.PKT 
~BYTE 0,4. 7;S.CTM,S.ITM 
-BYTE 0,0 ;S.STS,S.ST3 
-WORD S2.CON!S2.LOG ;S.ST2 
-WORD SDLA 3S.KRB 
-BYTE 5.,0 ;S.RCNT,S.ROFF 
«WORD 0 ;S.EMB 
. BLKW 6 ;MAPPING ASSIGNMENT BLOCK 
-WORD 0 ; KE. RHB 
DLA: 
Figure B-l Contiguous KRB/SCB for DLDRV 
Notes: 


1. K.VCT and K.CSR can be changed dynamically by reconfiguration 
commands when you bring the device on-line. Refer to the 
RSX-11M/M-PLUS System Management Guide, Chapter 15 for 
information on the Reconfiguration task and commands. 


2. Label DLA is used solely for calculating K.OFF (DLA-SDLA). 


B.2.3 The Controller Table 


RSX-11M-PLUS requires a Structure called a Controller Table (CTB). 
Add the code to define the CTB according to the rules described in 
Sections 4.2.5 and 4.4.8. An example of the code needed to define the 
CTB appears in Figure B-2. 


eWORD 0 ;L.ICB 
DLCTB: ;START OF CTB 

-WORD 0 7L.LNK 

e-ASCII /DL/ 7; L.NAM 

~-WORD SDLDCB 3;L.DCB 

~-BYTE 1,0 ;L.NUM,L.STS 
SDLCTB:: 

~WORD SDLA ;L.KRB 

Figure B-2 Controller Table (CTB) for DLDRV 

Notes: 


1. The symbol $DLDCB is a pointer to the Device Control Block 
(DCB). 


2. L.KRB points to the start of the KRB. 
This example assumes that you have a loadable data base. If the data 


base is resident, you must include the CTB macro before L.LNK. 


B-3 
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B.3 MODIFYING THE DRIVER CODE 


Several changes must be made to the RSX-11M driver code. For an 
overview of the RSX-l11M-PLUS coding requirements, refer to Section 
4.3. 


B.3.1 Conditional Symbols 


You can remove most dependence on system conditional definitions from 
the code. RSX-11M-PLUS always defines the symbols DSSIAG, MSSMGE, 
MSSEXT, MSSMUP, and ESSDVC. 


B.3.2 Controller-Dependent Code 


At the I/O initiation entry point in RSX-11M drivers, you will find 
code for defining a table of UCB addresses and loading the UCB address 
of the currently active unit in the _ table. Remove this code _ and 
replac2? it with the GTPKT$ macro call. For guidelines on doing this, 
refer to Sections 4.3.2 and 4.5.2. 


Following is an example of the RSX-11M driver code that you must 
remove: 


CALL SGTPKT ;GET AN I/O PACKET TO PROCESS 

BCC 1$ ;IF CC PROCESS REQUEST 

RETURN ;RETURN IF BUSY OR NO REQUEST 
1$: MOV R5,CNTBL(R3) ;SAVE ADDRESS OF REQUEST UCB 


Insert the RSX-11M-PLUS GTPKTS$ macro call, a sample of which follows: 


GTPKTS DL,RS$SL11 ;GET NEXT I/O PACKET TO PROCESS 


B.3.3 Driver Dispatch Table 


Replace the code that defines the entry point addresses with the DDTS$ 
macro call. Refer to Section 4.3.1 for a description of the call and 
its parameters. Refer to Section 4.5.1 for a description of the 
Driver Dispatch Table (DDT) and the format of the labels that it uses 
for the entry points. 


Following is an example of the RSX-11M driver code that you must 
replace: 


SDLTBL: : .WORD DLINI ;DEVICE INITIATOR ENTRY POINT 
-WORD DLCAN ;CANCEL I/O OPERATION ENTRY POINT 
-WORD DLOUT ;DEVICE TIMEOUT ENTRY POINT 
-WORD DLPWF ;POWERFAIL ENTRY POINT 


Insert the RSX-11M-PLUS DDT$ macro call, an example of which follows: 
DDTS DL, RSSL11 ;GENERATE DISPATCH TABLE 


You do not have to add code to the driver to handle controller and 
unit status changes. The sample form of the macro call shown 
generates code to use the xxPWF entry point for controller and unit 
on-line and off-line status changes. 
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B.3.4 Reconfiguration Support 


If you incorporate the device in the Reconfiguration task (HRC...) 
tables and the device calls the Executive volume valid routine, you 
must incorporate a local register pass routine in your driver, an 
example of which appears in Figure B-3. 


+ 


MOVE THE CONTROLLER/DRIVE REGISTERS INTO THE 
SPECIFIED BUFFER. 


; 
7 
; 
; INPUTS: 
: R2 = CSR ADDRESS 
; R3 = BUFFER ADDRESS 
H 
; OUTPUTS: 
; R3 - ALTERED 
Si 
REGPAS: MOV (R2) ,(R3)+ ;MOVE RLCS 
MOV RLBA(R2),(R3)+ ;MOVE RLBA 
MOV RLDA(R2),(R3)+ ;MOVE RLDA 
MOV RLMP(R2),(R3)+  ;MOVE RLMP 
CALL DLGST ;EXECUTE GET DRIVE STATUS FUNCTION 
MOV RLMP(R2) , (R3) ;SAVE DRIVE STATUS 
RETURN ; 
Figure B-3 Register Pass Routine (REGPAS) 
Notes: 


1. The index values RLxxx and the Subroutine DLGST are device 
specific. 


B.3.5 Volume Valid Processing 


If the device is a disk and has a volume valid function, the 
RSX-11M-PLUS Executive must be able to handle the correct function 
codes. Refer to the description of volume valid processing in Section 
4.5.9. For volume valid support, you may also need to include the 
code that appears in Figure B-4. 


CALL SVOLVD ; VALIDATE VOLUME VALID 
BCS IODON ;IF CS WE FAILED 
TST RO ; TRANSFER FUNCTION? 
BMI 1$ ;IF MI YES 
TST I. PRM+2 (R1) 7;SIZE THE DISK 
BPL IODON ;IF PL NO 
MOV S.CSR(R4) ,R2 ;RETRIEVE CSR ADDRESS 
CALL DLRST ;RESET DRIVE AND GET STATUS 
MOV S.PKT(R4),R3 ;RETRIEVE I/O PACKET ADDRESS 
CALL REGPAS ;PASS REGISTERS TO HRC 
BR IODON ;FINISH I/O REQUEST 
LS ;REFERENCE LABEL 


Figure B-4 Typical Handling of Volume Valid 


1. The subroutine DLRST is device specific. 
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B.3.6 Converting Logical Block Numbers 


The S$CVLBN routine converts a Logical Block Number (LBN) to a physical 


disk address. You can replace special-purpose code in the RSX-11M 
driver with a call to this Executive routine, a description of which 
is in Section 7.4.6. A sample of the code that you should remove 


appears in Figure B-5. 


MOV #40.,R1 ;DIVIDE BY SECTORS/SURFACE 

CALL SDIV ;CALCULATE CYLINDER NUMBER 

-REPT 6. 

ASL RO ;POSITION CYLINDER AND SURFACE 

- ENDR 

BIS R1,RO ;MERGE SECTOR WITH CYLINDER AND SURFACE 


Figure B-5 RSX-11M Logical Block Number Conversion 


Figure B-6 includes the call to S$SCVLBN. 


CALL SCVLBN ;CONVERT BLOCK NUMBER TO DISK ADDRESS 
ROR Rl ;PUT SURFACE BIT IN CARRY 

ROL R2 ;MERGE IT WITH THE CYLINDER NUMBER 

ASH #6,R2 ; POSITION CYLINDER AND SURFACE 

BIS R2,RO ;MERGE SECTOR WITH CYLINDER AND SURFACE 


Figure B-6 RSX-11M-PLUS Logical Block Number Conversion 


B.3.7 Interrupt Entry Processing 


Ensure that the INTSVS$ macro call appears as the first line of code at 
each interrupt entry point in the driver. Refer to Section 4.3.3 for 
a description of the INTSV$ macro call and to Section 4.5.8 for a 
discussion of processing at an interrupt entry point. Following, is a 
sample INTSV$ macro call: 


INTSVS DL,PR5,RS$L11 773¢SAVE REGISTERS AND SET PRIORITY 


INDEX 


ABODFS, A-3 
Acceptance routine, 1-13 
Access path, 

switching between, 1-11 
Accounting block offsets, A-4 
Accumulation fields, 

See ACNDFS 
SACHCK routine, 7 
SACHKB routine, 7 
ACNDFS, A-4 to A-9 
ACP function mask, 4-19 to 

4-20 
ACTDFS, A-10 
Active Page Register, 

See APR, 1-2 
Address doubleword, 7-1 to 7-2 
Advance driver feature, 1-7, 

1-10 to 1-16, 2-4 
SALOCB routine, 7-8 
APR, 1-2 to 1-3 
AST, 1-14 
SASUMR routine, 7-9 

calling from driver, 7-4 
Asynchronous System Trap, 

See AST 


-7 
-7 


SBLKC1 routine, 7-10 
SBLKC2 routine, 1-16, 7-10 
SBLKCK routine, 1-15, 7-10 
SBLXIO routine, 7-11 
Breakpoint, 

setting in a driver, 6-5 
Buffer, 

Special uSer, 

sample of driver handling, 
8-12 to 8-25, A-26 

Buffered I/O, 1-14 
Bus switch, 1-16 


Cancel I/O, 
entry point, 4-64 to 4-65 
overview, 2-5 
SCFORK, 1-17 
CINTS directive, 1-1 
SCKBFB routine, 7-12 
SCKBFI routine, 7-12 
SCKBFR routine, 7-12 
SCKBFW routine, 7-12 
SCLINS routine, 7-13 
CLKDFS$, A-1l 
Clock queue control block, 
offset definitions, A-1l 


Index-1l 


Common interrupt dispatching, 
1-12 
CON task, 1-18, 5-2, 5-7 to 
5-9 
overview, 1-18 
Concurrent I/0, 1-13 
Conditional assembly 
directive, 4-2 
Conditional fork, 1-17 to 1-18 
necessity, 1-17 
Configuration, 
peripheral, 
choosing, 5-10 to 5-11 
Connectivity mask, 1-17 
Contiguous KRB and SCB, 2-2, 
4-53 
Control and Status Register, 
See CSR 
Control function mask, 4-19 to 
4-20 
Controller, 1-4 
2-level controllers, 1-13 
access, 1-10 to 1-ll 
delayed, 1-11 
dual support, 1-11 
access list, 2-2 
allowing parallel 
operations, 2-2 
assignment, 1-11 
busy/not busy, 1-11 to 1-12 
configuration status for, 
2-2 
defining type, 2-1 
group number, 1-7 
I/O count, 1-12 to 1-13 
interrupt vector, 1-7 
interrupts, 1-1ll 
location of a CSR for a, 2-2 
maintaining hardware- 
specific information 
for, 2-2 
making accessible, 5-6 
name, 2-1 
number, 1-5 
placing on line, 5-7 
reassignment and load 
sharing, 1-11 
status, 1-11 
subcontroller device, 1-13 
block, 1-13 
supporting more than one 
device, 1-12 
Controller reassignment, 1-11 
Controller Request Block, 
See KRB 


INDEX 


Cortroller request queue, 
l-1l1l, 2-2 
Controller status change, 
entry point, 4-66 to 4-68 
overview, 2-6 
Controller status extension 2, 
4-42 
Controller status extension 3, 
4-41 
Controller status word, 4-48 
Controller table, 
See CTB 
Controller table status byte, 
4-58 
Conversion routine, 1-15 
Crash dump analysis, 
See CDA 
CSR, 1-1 
accessing of, 1-1 
ajidress space, 1-1 
assignment error, 5-8 
assignments, 
setting, 5-6 
CTB, 
composite arrangement, 3-15 
d2finition, 1-4 
datails, 4-53, 4-55 to 4-59 
format, 4-55 to 4-59 
layout, 4-55 
overview, 2-1 
r2quirement, B-3 
system list, 2-1 
use in handling interrupts, 
2-1 
validation during LOAD, 5-12 
/CTB; 
use in LOAD, 5-14, 6-15 
CTBDFS, A-12 
SCT.UST symbol, 2-1, 3-15 
SCV.LBN routine, 7-14 
Cylinder number, 1-15 
Cylinder Scan, 
definition, 1-15 


D.xxx offsets, 
in DCB, 4-16 to 4-18 
Data base, 1-18 
assembling, 
during system generation, 
5-3 
code, 
bit symbols, 4-30 to 4-31 
converting RSX-11M to 
RSX-11M-PLUS, 
defining CTB, B-3 
disk geometry 
calculations, B-2 
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Data base (Cont.) 
modifying the data base, 
B-1 
creating source code, 4-2 
defining link word for, 4-3 
details of structures, 
4-31 to 4-37, 4-39, 
4-49 to 4-53 
driver, 
sample code, 8-1 to 8-3 
Structures, 
overview of, 2-1, 2-3 
global label, 4-2 
SUSRTB, 4-3 
$xxDCB, 4-3 
labeling of data structures, 
4-2 
loadable, 1-19, 4-3 
incorporating, 5-1 
modifying RSX-11M to 
RSX-11M-PLUS, B-1l 
SCB requirements, B-2 
module, 
inserting into library, 


5-4 
overview of structures, 
2-2 to 2-3 


owning CTB, 2-1 
programming, 
requirements, 4-2 to 4-3 
resident, 1-19, 4-3 
incorporating, 5-1 
link to CTB, 4-3 
structures, 
augmented, 1-13 
composite arrangement, 2-11 
conventional, 1-13 
ordering of, 4-2 
typical arrangements, 
2-6 to 2-8 
validation during LOAD, 5-12 
Data structure, 1-13 
definitions, A-1l to A-7l, 
B-72 
Data transfer, 1-14 
DCB, 
ASCII device name, 4-17 
compoSite arrangement, 2-11 
creating mask words in, 4-21 
definition, 1-4 
details, 4-16 to 4-18 
driver dispatch table 
pointer, 4-18 
driver-specific function 
masks, 4-18 to 4-26 
establishing characteristics 
for, 2-7 
establishing I/O function 
masks, 4-22 
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DCB (Cont.) 
fields, 4-16 to 4-18 
format, 4-16 to 4-18 
labeling, 4-3 
length of UCB, 4-18 
link to next DCB, 4-16 
list of, 2-3 
means to access Driver 
Dispatch Table, 2-2 
number of units stored, 4-3 
overview, 2-2 to 2-3 
pointer to first UCB, 4-17 
unit number range, 4-18 
validation during LOAD, 5-13 
DCBDFS, A-13 
DDTS macro call, 
arguments, 4-5 to 4-6 
use of, 4-4 
SDEACB routine, 7-15 
Deallocation entry point, 
4-66 
Delayed Controller access, 
1-11 
SDEUMR routine, 7-16 
calling from driver, 7-4 
SDEVHD routine, 2-3, 2-11 
Device, 
address, 1-l 
asSigned controller, 1-18 
busy/not busy, 1-13 
configured on-line, 1-13 
dual-access capability, 1-17 
generic name, 2-3 
interrupt, 1-5 
making accessible, 5-6 
registers, 1-1 to 1-2, 4-50 
storage of static 
characteristics, 2-3 
Ssubcontroller, 1-13 
Device Control Block, 
See DCB 
Device driver, 
See Driver 
Device interrupt address, 
overview, 2-6 
Device interrupt vector, 2-4 
Device timeout, 
entry point, 4-65 
overview, 2-5 
Directive Parameter Block, 
See DPB 
Disk, 
geometry calculations, B-2 
Distributed I/0, 1-16 
Doubleword, 
address, 7-1 to 7-2 
DPB, 4-11 
details, 4-14 to 4-15 
format, 4-14 to 4-15 
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DPB (Cont.) 
I/O function allowances, 
4-19 
usage in creating I/0 
packet, 3-2 
DRDSP, 
directive dispatcher, 3-2 
Driver, 
acceptance routine, 1-13 
accessing a controller, 1-17 
advanced features, 1-10 to 
1-16, 2-4 
assembling, 
during system generation, 
5-3 
building, 
loadable, 5-2 
resident, 5-2 
code, 1-19 
creating, 4-4 
definition, 1-5 
function, 4-4 
general description, 4-4 
requirements, 4-59 
usage of symbolic offsets, 
4-59 
coding, 1-3 
conversion routine, 1-15 
converting RSX-11M to 
RSX-11M-PLUS, 
adding GTPKTS, B-4 
adding the DDTS$ macro 
call, B-4 
conditional symbols, B-4 
handling function codes, 
B-6 
interrupt entry point, B-6 
LBN converSion, B-6 
modifying the driver code, 
B-4 
reconfiguration Support, 
B-5 
using S$CVLBN, B-6 
using INTSVS, B-6 
volume valid processing, 
B-5 
creating source code, 4-4 
data base, 1-4, 1-18 
linkages, 1-18 
data structure, 1-4, 4-27 
accesSing, 4-2 
details, 4-10 
symbolic offsets, 4-2 
DDTS$ macro call, 
arguments, 4-5 to 4-6 
placement of, 4-5 to 4-6 
debugging, 2-20, 6-1 to 6-6, 
6-8, 6-10 to 6-12, 7-13 
using CDA, 6-1 
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using XDT, 6-1 
defining labels, 4-60 
details of code, 4-59 to 
4-69, 5-70 
entry points, 1-4, 2-4 
See Driver entry point, 4-62 
executable instructions, 1-4 
executing on correct 
processor, 1-18 
Executive, 
choosing options, 5-9 to 
5-11 
Executive services, 
typically used, 3-4 to 
3-5, 4-6 
fer NPR devices on PDP-1ll, 
7-2 
full—-duplex, 4-13 
GTPKTS$S macro call, 
arguments, 4-7 
Placement of, 4-7 
hendling full-duplex 
operations, 1-13 
handling multiple I/0 
requests, 1-13 
I/O packet, 1-4 
I/O queue, 
placement of I/0 packet, 
4-11 
IvyO request, 
function codes for, 4-13 
Processing, 1-15 to 1-16 
I/O requirements, 4-19 
incorporating, 1-18 to 1-19, 
5-1 
at system generation, 5-1 
guidelines for, 5-1 
loadable, 5-1 
resident, 5-1 
ir.itiating I/O, 1-17 
irterrupt handling, 1-8 
irterrupt level, 1-6, l- 
interrupts, 7-1 
INTSV$ macro call, 
arguments, 4-8 
Placement of, 4-8 
leadable, 
definition, 1-2 
entry points for LOAD and 
UNLOAD, 4-9 
incorporating, 5-1 
after system generation, 
5-2 
at system generation, 5-1 
overview, 1-18 
rebuilding and 
reincorporating a, 
7-13 
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with loadable data base, 
1-19 
with resident data base, 
1-19 
loadable data baSe, 
incorporating, 5-1 
after syStem generation, 
5-2 
loading, 5-5 
macro call, 4-4 to 4-5 
mapping with Executive, 


L=2 -to- i=3 
modifying data in UCB, 2-3 
module, 
inserting into library, 
5-4 


partition, 5-5 
predriver initiation, 3-2 
process, 1-11 

definition, 1-5 
processing, 

I/O request, 1-4, 3-3 

interrupts, 1-6 
programming, 

conventions, 4-1 

requirements, 4-4 to 

4-9 
protocol, 1-8, 4-1 
requesting I/O packet, 1-5, 
1-17 
resident, 1-18 
definition, 1-2 
incorporating, 5-1 
at system generation, 
5-2 
overview, 1-18 
with resident data base, 
1-19 
sample source code, 8-3 to 
8-12 
servicing, 

I/O request, 1-4 
specifying as loadable, 4-9 
standards, 4-1 
system generation, 5-4 to 


5=<5 
dialogue summary, 5-9 
effect, 5-3 


system macro call, 
arguments, 4-5 
general functions, 4-5 
task-building, 5-4 to 5-5 
types of, 1-2 
UMR procedures, 7-2 to 


7-5 
XDT support, 6-1 
Driver Dispatch Table, 4-4 
address of routines, 1-4 
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Driver Dispatch Table 
(Cont.) 
entry points, 2-4 
association of, 4-60 
format, 4-60 
generation of, 4-4 
from DDTS$, 4-60 
labels required, 4-60 
layout, 4-61 
link to the driver code and 
data base, 4-60 
Driver entry point, 2-4 
block check and conversion, 
4-62 
cancel I/O, 4-62, 4-64 to 
4-65 
controller status change, 
4-62, 4-66 to 4-68 
deallocation, 4-66 
device timeout, 4-62, 4-65 
I/O initiation, 4-62 to 4-64 
interrupt, 4-62, 4-69, 5-70 
next command, 4-65 
power failure, 4-62, 4-66 
queue optimization, 4-65 
Standard labels, 4-62 
unit status change, 4-62, 
4-68 to 4-69 
DRQIO, 
performing redirect 
algorithm, 3-2 
SDRORQ routine, 1-15 
locating the conversion 
routine, 1-15 
DTO7 bus switch, 1-16 
Dual access, 1-11 to 1-12 
operation of, 2-10 
Dual-access support, 1-11 
SDVMSG routine, 7-17 


Elevator, 
definition, 1-15 
EPKDFS, A-14 to A-20 
Executive, 
calling the driver, 1-17 
coroutine, 
SINTSV, 1-6 
directive dispatcher, 
DRDSP, 3-2 
dispatching to correct 
driver routine, 2-1 
distributing I/O requests, 
1-17 
handling, 
interrupts, 2-1 
routines, 1-5 to 1-6 
interrupt exit routine, 1-6 
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Executive (Cont.) 
interrupt save routine, 

1-6 to 1-7 

macro library, 

EXEMC.MLB, 5-3 
maintaining controller and 
hardware specific 
information, 2-1 

mapping of, 1-3 
modifying data in UCB, 2-3 
module, 
DVINT, 1-12 
options for driver, 5-9 to 
5-11 
performing processor 
specific functions, 1-16 
predriver initiation, 1-4 
queuing to the driver, 1-4 
request queue for 
controller, 1-11 
service routine, 1-2 to 1-3 
stack and register dump, 
6-11 
symbol, 
SCTLST, 3-15 
Executive Debugging Tool, 
See XDT 
Executive routine, 1-12, 1-15, 
4-4] 
See also Executive services 
SGTPKT, 1-5, 1-13 
SIODON, 1-9 
Executive services, 
Summaries of technically 
used, 7-5 to 7-39, 8-40 
EXELIB.OLB file, A-1l 
EXEMC.MLB file, A-1 
Extended User Control Block, 
See UCB 
External header, 6-8 


F11IDFS$, A-21 to A-24 
Fault, 
tracing, 6-8, 6-12, 7-13 
Fault codes, 6-10 
Fault isolation, 6-5, 6-7 to 
6-8 
FCB, 2-14 
File Control Block, 
See FCB 
Fork block, 1-17 
storage area, 4-39 
Fork list, 
head of (SFRKHD), 2-14 
Fork process, 1-9, 1-18 
definition, 1-8 
Fork processing, 1-14 
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Fork routine, 1-8 
SFCRK routine, 1-9, 1-18, 7-18 
criver use in I/0 
processing, 3-5 
SFCRK1 routine, 7-19 
SFFKHD symbol, 2-14 
Full-duplex I/0, 1-13 
Furction mask, 
ACP, 4-19 to 4-20 
building for mask word, 4-21 
control, 4-19 to 4-20 
establishing, 4-22 
layout, 4-19 to 4-20 
legal, 
details, 4-19 to 4-20 
no-op, 4-19 to 4-20 


SGSPKT routine, 1-13 to 1-14, 
7-21 to 7-22 
SGT8YT routine, 7-20 
SGTPKT routine, 1-5, 1-13, 
1-16, 7-21 to 7-22 
usage in driver code, 3-5 
GTPXTS macro call, 
arguments, 4-7 
SGTWRD routine, 7-23 


Harlware configuration, 
r2lationship to structures 
at block level, 2-1 
HDROFS$, A-25 to A-26 
SHEA\DR, 6-7, 6-9 
pointer to first word of 
task header, 6-8 
Hig i-speed device, 1-16 
HWDIFS, A-27 to A-30 


I.xxx offsets, 
in I/O packet, 4-11 to 4-14 
T/o. 
cancel in-progress, 2-5 
h gh-speed devices, 1-14 
overview, 3-4 
p:ocessing requirements, 
1-15 
S' ow-Speed devices, 1-14 
T/O count, 1-12 
I/O data base structure, 
composite arrangement, 2-11 
t.pical arrangements, 2-7 to 
2-8, 2-10 
I/O data structure, 
details, 4-10 


I/O data structure (Cont.) 
overview, 2-1 to 2-3 
typical arrangements, 2-6 

I/O finish, 

See SIOFIN routine 

I/O function, 
definition of types, 3-3 
mask values, 4-23 
mask word bit settings, 

4-24 to 4-26 

I/O function mask, 
establishing, 4-22 

I/O initiation, 
entry point, 4-63 to 4-64 

sample use of alternative, 
8-12 to 8-25, A-~-26 
overview, 2-5 

I/O packet, 1-4 
building, 4-11 
composite arrangement, 

2-13 to 2-14 
creation of, 3-2 
current address, 4-40 
fields, 4-11 to 4-14 
handling before it is 
queued, 8-12 to 8-25, 
A-26 
layout, 4-11 

I/O page, 1-3 

I/O queue, 
listhead, 4-39 

I/O Queue Optimization, 
Cylinder Scan, 1-15 
Elevator, 1-15 
Nearest Cylinder, 1-15 

I/O request, 1-4 to 1-5, 1-15 
completing process for an, 

3-4 
flow of, 3-1 to 3-4 
issuing I/O for an, 3-4 

ICB, 1-2, 1-6, 1-12, 1-18, 2-4 

number of controllers 
allowed, 1-7 

SINIBF routine, 1-14, 7-24 

SINISI routine, 1-6 

INITL module, 
errors from, 6-3 

Interrupt, 1-l 
addresses, 

overview, 2-6 
connect-to directive, 1-1 
dispatching, 1-7 
for common interrupt 
devices, 1-12 
overview, 2-6 
entry address, 2-4 
for overlapped seek, 1-12 
handling, 1-5, 1-7 to 1-9, 
1-12 
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Interrupt (Cont.) 
processing by driver, 3-4 
protocol, 1-6, 1-9 
service routine, 1-5 to 1-6 
vector, l-l, 1-12 
Interrupt Control Block, 
See ICB 
Interrupt entry point, 4-69, 
5-70 
Interrupt save, 
See SINTSV routine 
SINTSI routine, 1-7 
SINTSV routine, 1-6 to 1-7, 
7-25 
INTSVS macro call, 
arguments, 4-8 
SINTXT routine, 1-6 
SIOALT routine, 1-1 
7-27 
driver use in I/0 
processing, 3-5, 4-6 
SIODON routine, 1-9, 1-13, 
7-27 
driver use in I/0 
processing, 3-5, 4-6 
SIOFIN routine, 1-13 to 1-14, 
3-3, 7-28 
IOSB, 
validity checks, 3-2 
ITBDFS$, A-31 


1 7-26 
3, 1-15, 


K.STS, 4-48 
K.xxx offsets, 
in KRB, 4-47 to 4-48, 
4-50 to 4-52 
KRB, 1-13 
access queue in the, 2-2, 
3-15 
combined with SCB, 2-2, 4-53 
layout, 4-54 
composite arrangement, 3-15 
configuration status in the, 
2-2 
contiguous with SCB, 2-7, 
4-3 
controller status register, 
4-50 
defining start of addresses, 
4-3 
definition, 1-4 
details, 4-45, 4-47 to 4-53 
format, 4-47 to 4-53 
layout, 4-46 
overview, 2-1 to 2-2 
subsets, 1-13 
use in determining 
interrupting unit, 2-2 
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validation during LOAD, 5-12 
KRB1, 1-13 
KRBDFS, A-32 to A-33 


L.STS, 4-58 
L.xxx offsets, 
in CTB, 4-55 to 4-56, 
4-58 to 4-59 
LBN, 1-15 
LCBDFS$, A-34 
LD$xx symbol, 4-9 
Legal function mask, 
details, 4-19 to 4-20 
LOAD command, 1-18 to 1-19, 
2-20, 5-2 
allowances, 1-7 
Executive operation for 
driver, 5-11 
operation, 5-11 
overview, 1-18 
use of /CTB, 5-14 
Load sharing, 1-11 
Loadable data base, 
See Data base 
Loadable driver, 
See Driver 
Logical block number, 
See LBN 
Logical unit table, 
See LUT 
LPA11-K, 1-13 to 1-14 
LUT, 2-11, 3-2 


Mask word, 
creating, 4-21 
I/O function, 4-21 
MASSBUS, 
controller, 1-13 
mixed device, 1-12 
Mixed MASSBUS device, 1-12 
SMPUB1 routine, 7-30 
SMPUBM routine, 7-29 
MTADFS, A-35 to A-38 
Multiple access operation, 
data base structures, 2-8, 
2-10 
Multiple controller, 1-7 
Multiprocessor system, 
task issuing I/O request, 
1-16 


INDEX (CONT.) 


Neazest Cylinder, 

d2finition, 1-15 
Nex& command entry point, 4-65 
No-op function mask, 4-19 to 


4-20 
Non-pool-resident, 6-8 
header, 6-9 


Non2xternal header, 6-8 
NPR device, 
drivers for (on PDP-11), 7-2 


OLRDFS$, A-39 to A-46 
Overlapped Seek I/O, 1-11 
data base structures, 2-8 
data transfers, 1-10 
difficulty factor, 1-10 
executing parallel 
operations, 1-10 


Page Address Register, 
S2e PAR 
Page Description Register, 
See PDR 
PAR, 1-2 
Parallel un:t operation, 
data base structures, 2-8 
Partition Control Block, 
See PCB 
PCB, 
composite arrangement, 2-11 
PCBDFS, A-47 to A-50 
PDR, 1-2 
Peripheral configuration, 
choosing at system 
generation, 5-10 to 5-11 
PKTDFS, A-51 to A-56 
Pool-resident, 6-8 
header, 6-9 
Ports, 1l-1ll 
switching between, 1-12 
Power failure, 
entry point, 4-66 
overview, 2-6 
Predriver initiation, 
processing during, 3-2 to 
3-4 
Primary UNIBUS run, 1-17 
Processor, 
halt, 
tracing fault, 6-11 
loop, 
tracing fault, 6-12 
Processor-specific functions, 
1-17 
SPTBYT routine, 7-31 
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SPTWRD routine, 7-32 


Q.xxx offsets, 
in I/O packet, 4-15 to 4-16 
SQINSP routine, 7-33 
QIO directive, 
building I/O packet, 4-11 
creating DPB, 3-2 
directive dispatching, 3-2 
QIO Directive Parameter Block, 
See QIO DPB 
QIO DPB, 4-12, 4-15 to 4-16 
QIO request, 2-11 
SQUEBF routine, 1-14 
Queue optimization, 1-15 
entry point, 4-65 


Redirect algorithm, 3-2 
Register, 

conventions, 

at system state, 7-1 

SRELOC routine, 7-34 
SRELOP routine, 7-35 
SREQU1 routine, 7-36 
SREQUE routine, 7-36 
Resident data baSe, 

See Data base 
Resident driver, 

See Driver 
SROCNC, 4-41 
SROCND, 4-41 
RSXASM.CMD file, 5-3 


S.ST2, 4-42 
S.ST3, 4-41 
S.STS, 4-41 
S.xxx offsets, 
in SCB, 4-39 to 4-45 
SAB, A-5 
SSAHDB, 6-9 to 6-10 
contains an unknown value, 
6-8 
SSAHPT, 6-9 
pointer to first word of 
task header, 6-8 
SSAVSP, 6-9 
pointer to first word of 
task header, 6-8 
SCB, 1-13, 2-2 
adding KRB, B-2 
address for KRB, 2-3 
changes for converting a 
driver, B-2 
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SCB (Cont.) 
combined with KRB, 4-53 
layout, 4-54 
composite arrangement, 
2-13 to 2-14 
contiguous with KRB, 2-7, 4-3 
details, 4-37, 4-39 to 4-44 
format, 4-39 to 4-44 
KRB addresses for, 4-45 
layout, 4-38 
link to fork blocks, 2-3 
overview, 2-3 
parallel operations, 2-3 
pointer, 
to currently assigned KRB, 
4-44 
to head of queue for I/0 
requests, 2-3 
validation during LOAD, 
5-13 to 5-14 
SCBDFS, A-57 to A-58 
Secondary UNIBUS run, 1-17 
Serial operations, 
single controller, 2-7 
Serial unit operation, 
data base structures, 2-7 
multiple units per 
controller, 2-7 
Service routine, 
See also Executive services 
summaries of Executive, 3-5, 
4-6, 7-5 to 7-39, 8-40 
SHDDFS, A-59 to A-60 
SPR, 2-20 
Stack and register dump, 
Executive, 6-11 
Stack depth indicator, 6-8 
Stack structure, 6-12 
internal SST fault, 6-10 to 
6-11 
Static structure, 2-1 
Status Control Block, 
See SCB 
SSTKDP, 6-8, 6-11 
Stack Depth Indicator, 6-7 
SSTMAP routine, 7-37 
calling from the driver, 7-3 
SSTMP1] routine, 7-38 
calling from the driver, 7-3 
Subcontroller device, 1-13 
block, 1-13 
Symbolic offsets, A-l 
usage, 4-2 
SYSTB.MAC file, 1-18 
system, 
data structures, 
abort codes, A-3 
macro definitions, A-1 to 
A-71, B-72 
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stack, 6-11 
System Account Block, A-5 
System generation, 
incorporating a driver, 5-1 
System I/O data base, 
main thread through, 2-1, 
2-3 
System macro call, 4-5 
System-state, 
register convention, 7-1 


TAB, A-5 
Task, 
checkpointing, 1-14 
decrementing I/O count, 1-14 
frequency of accessing data 
areas, 1-15 
proper state to initiate 
buffered I/O, 1-14 
Task Account Block, A-5 
Task Control Block, 
See TCB 
Task header, 6-9 
composite arrangement, 2-13 
pointers, 6-8 
TCB, 1-14 
composite arrangement, 2-1ll 
TCBDFS$, A-61 to A-64 
Timeout count, 
initial, 4-40 
Timeout entry point, 
overview, 2-5 
STKTCB, 
pointer to current TCB, 6-7 
Tracing fault, 6-8, 6-12, 7-13 
Transaction file, 
SAB, A-5 
TAB, A-5 
UAB, A-5 
STSPAR routine, 7-39 
STSTBF routine, 1-14, 8-40 


U.ST2, 4-32 

U.STS, 4-31 

U.xxx offsets, 
in UCB, 4-27 to 4-37 

UAB, A-5 

UCB, 1-13 to 1-14 
association with SCB, 2-7 
composite arrangement, 2-13 
details, 4-27 to 4-37 
device-dependent values, 

4-29 
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UCB (Cont.) 
device-specific 
characteristics, 4-32 to 
4-35 
disk geometry calculations, 
B-2 
enabling driver to access 
data structures, 2-3 
fields, 4-27 
format, 4-27 to 4-37 
layout, 4-28 
length, 4-3 
Stored in DCB, 2-3 
ordering, 4-3 
overview, 2-3 
pointer, 
to associated DCB, 4-29 
to I/O structures, 2-3 
to start of this UCB, 4-29 
table, 
composite arrangement, 
3-15 
validation during LOAD, 5-13 
UCBDF$, A-65 to A-71, B-72 
UCBSV, 
usage in macro calls, 4-8 
UMR, 
Programming procedures, 
7-2 to 7-5 
UNIBUS, 
Switched bus, 1-16 
UNIBUS Mapping Registers, 
See UMR 
UNIBUS Run Mask, 
See URM 
Unit, 
making accessible, 5-6 
Placing on line, 5-7 
Unit Control Block, 
See UCB 
Unit status byte, 4-31 
Unit status change, 
entry point, 4-68 to 4-69 
overview, 2-6 
Unit status extension 2, 4-32 
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URM, 1-16, 4-39 
User Account Block, A-5 
SUSRTB global label, 4-3 


VCB, 
composite arrangement, 3-15 
Vector, 
addresses, 
definition of in Driver 
Dispatch Table, 2-6 
assignment, 
setting, 5-6 
assignment error, 5-8 
interrupt, 1-l, 1-12 
Volume Control Block, 
See VCB 
Volume valid processing, 5-70 


Window block, 
composite arrangement, 2-14 


XDT, 6-1 to 6-3, 6-5 
commands, 6-2 
debugging, 

driver, 6-2, 6-4 to 6-5 
general operation, 6-4 
restrictions, 6-3 
Startup, 6-2 

xxCTB label, 4-60 

$xxDCB, 
global label, 4-3 

xXDRV.MAC file, 5-2 

xXDRVASM.CMD file, 5-3 

SxxLOA label, 4-9, 4-61 

XxXTAB.MAC file, 1-18, 5-2 

SxxTBE label, 4-60 

SxxTBL label, 4-60 

SxxUNL label, 4-9, 4-61 
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